YamaKen
yamak****@bp*****
2005年 1月 30日 (日) 05:41:44 JST
ヤマケンです。議論へのお付き合いありがとうございます。 どうもお互いに誤解が生じているようなので順を追って解説します。 まず、私はdefine-keyとuim-pref上の表現は非互換になる事を前提に話 をしていました。この点で話が食い違っていたのかもしれません。 非互換性はもちろん望ましくないんですが、これについては0.4.6以降 で予定しているキー入力表現の拡張を行った時に再編する事になると思 います。 define-keyに渡したキー表現はこれまでもこれからも暗黙に以下のよう な内部表現に変換されて登録されています。 "J" → "<IgnoreRegularShift>J" "j" → "<IgnoreRegularShift>j" "<Control>J" → "<IgnoreRegularShift><Control>J" "<Control>j" → "<IgnoreRegularShift><Control>j" この<IgnoreRegularShift>というprefix(translater prefixと呼びます) は入力がisprint(3)な文字の場合のみ<Shift>を無視する事を指示しま す。他の条件(modifierのあるなし、case sensitivity等)には一切関与 しません。 内部表現 : マッチする入力 "<IgnoreRegularShift>J" : "J", "<Shift>J" "<IgnoreRegularShift>j" : "j", "<Shift>j" "<IgnoreRegularShift><Control>J" : "<Control>J", "<Control><Shift>J" "<IgnoreRegularShift><Control>j" : "<Control>j", "<Control><Shift>j" このdefine-keyの挙動はそのままに、uim-prefが保存する設定のみを変 更する事を意図していました。~/.uim.d/customs/custom-global-keys.scm ではdefine-keyの代わりに、make-key-predicateを使って生の設定をそ のまま保存するようにしています。 At Sat, 29 Jan 2005 11:36:18 +0900, ekato****@ees***** wrote: > On Sat, Jan 29, 2005 at 05:40:58AM +0900, > YamaKen <yamak****@bp*****> wrote: > > > At Fri, 28 Jan 2005 18:11:14 +0900, > > ekato****@ees***** wrote: > > > ぼくだったら、uim-pref 上の表示として > > > > > > o アルファベットキーのみでは、case を区別する。 > > > o modifier 付きのキーでは case を区別せず小文字で表記する (<Control>j > > > のように) > > > > > > とするかもしれません。 > > ちょっと考えてみたんですが、ルールが複雑になりすぎると思います。 > > > > Caps Lockがonの状態では"l"を入力しようとするとShiftを押す事にな > > るため、"<Shift>l"として渡ってきます。このため、1つの表現でCaps > > Lock on/offの両方に対応しようとすると、caseの区別に加えて<Shift> > > の無視を暗黙に行う必要があります。 > > そうです。shift mask については他の modifier mask が無くアルファベット > キーのみのときは、その mask を無視して、アルファベットの case を区別す > るということを意図していました。 > > つまり、"l" が欲しいのであれば、caps lock 無してあれば、l キーを押して > uim-pref 上に "l" を得る、caps lock 有りであれば、shift キー と l キー > を押して、uim-pref 上に "l" を得る。 > > > > 一方、このルール上で"J"に加えて<Control>が押されている事を検出し > > ようとすると"<Control><Shift>j"と表現される事になります。この場 > > 合は"J"の場合とは逆にcaseが無視され、さらにユーザが目にする表現 > > に<Shift>が加わります。 > > そうですか? 加藤さんの案では「modifier 付きのキーでは case を区別せず小文字 で表記」というルールが存在するので、<Control>が押されている状態 でなおかつ<Shift>を押している/いない、もしくは大文字/小文字の区 別を行いたい場合には、どうしてもユーザ向け表現に"<Shift>"を加え る必要があります。 加藤さん案は以下のような対応になります。 Caps ユーザ入力 マッチするuim-pref表現:内部表現 off : "j" → "j" : "<IgnoreRegularShift>j" on : "<Shift>j" → "j" : "<IgnoreRegularShift>j" off : "<Shift>J" → "J" : "<IgnoreRegularShift>J" on : "J" → "J" : "<IgnoreRegularShift>J" off : "<Control>j" → "<Control>j" : "<IgnoreCase><Control>j" on : "<Control><Shift>j" → "<Control><Shift>j" : "<IgnoreCase><Control><Shift>j" off : "<Control><Shift>J" → "<Control><Shift>j" : "<IgnoreCase><Control><Shift>j" on : "<Control>J" → "<Control>j" : "<IgnoreCase><Control>j" > これまでの uim の挙動として、modifier が有る場合には caps lock があっ > てもなくても同様に機能するように <Control>j と <Control>J は区別しない > よう両方とも同じ意味として *.scm に設定してありますよね。 > > そうであれば、"J" + <Control> というのは、"j" + "<Control>" でもいいわ > けで、uim-pref 上で "<Control>j" という表記でかまわないと思います。 > 意味的にも、ユーザとしては、caps lock 有っても無くても、Control キーと > j キーの組み合わせを意図しているわけですから、表示と食い違いはありませ > ん。 この点については問題にしていません。 旧来のdefine-keyではCaps Lockのon/offにかかわらずユーザがShift + jキーを押した事を検出するために"<Control>J","<Control>j"の2通り の表現を登録していました。 私の提案では、Caps Lockのon/offにかかわらず Control + jキーを1つ の表現でまとめてマッチさせるためにuim-pref上では"<Control>j"、内 部表現では"<IgnoreCase><Control>j"として扱う事を意図していまし た。ここまでは加藤さん案でも同等の動作になります。 一方、私が加藤さん案に対して問題にしているのはユーザが明示的に <Control><Shift>を押している事を検出したい場合です。加藤さんはこ れを想定していない、もしくは不要だと思っているように見えます。 > この場合に、 「shift を押す」というのは、shift mask を付けるという意味 > ですから、caps lock が有っても無くても (アルファベットの case を無視し > て)、<Control><shift>j という別の意味のキー設定になり、uim-pref 上に > "<Control><shift>j" と表示されて問題ありません。 > > > <Control>を加えただけでこのような表現の変化が生じると、一貫性の > > 無さによりユーザの理解を妨げる事になると思います。 > > ちょっと良くわかりませんでした。 Caps Lockなしの場合で言うと、加藤さん案では<Shift>jというユーザ 入力が"J"、<Control><Shift>jが"<Control><Shift>j"としてユーザに 見える事になり、<Shift>jの表現が<Control>のあるなしで変化する事 になります。これを指して一貫性が無いと表現しました。 上記の表で言うと、以下のパターンです。 Caps ユーザ入力 マッチするuim-pref表現 on : "<Shift>j" → "j" off : "<Shift>J" → "J" on : "<Control><Shift>j" → "<Control><Shift>j" off : "<Control><Shift>J" → "<Control><Shift>j" 一方、私の案ではuim-pref上の表現は"<Shift>j"、 "<Control><Shift>j"となり、<Control> のありなしにかかわらず <Shift>jの表現は一貫しています。 Caps ユーザ入力 マッチするuim-pref表現 on : "<Shift>j" → "<Shift>j" off : "<Shift>J" → "<Shift>j" on : "<Control><Shift>j" → "<Control><Shift>j" off : "<Control><Shift>J" → "<Control><Shift>j" > > 上記の"l"の例はskkでは起こり得ないシチュエーションですが、anthy > > でskk風モード遷移を使っている場合にはCaps Lockしたまま操作する場 > > 合に発生します。 > > 確かにこの場合は (アルファベットキーのみで case を無視した挙動が欲し > い場合)、l の case を区別すると問題になりますね。ユーザに明示的に、"L" > も追加してもらうという方法になるでしょうか。 uim-pref上で"L"を登録するためには、最初に"<Shift>L"をキャプチャー してから<Shift>のチェックを外すという操作、もしくはCaps Lock on 状態で"L"を入力する事が必要になります。 はたしてこれらの表記の違いと意味をユーザに理解させる事が可能だろ うか、というのが今回の提案のそもそもの動機になっています。 私の結論は「無理」です。なので、ユーザが押した通りのキーをキャプ チャーするだけで登録が可能で、かつ表記が一貫している必要があると 考えました。 このへんがemacsの影響が色濃く出ていて、かつ手入力なdefine-keyと 事情の違うところです。 > > 一方で加藤さんの言う気持悪さというのも理解できるので、以下のよう > > な妥協案はどうでしょうか。 > > > > ・アルファベットキーはuim-pref上では常に *小文字* で表す > > ・アルファベットキーに対する<Shift>の暗黙無視を行わない > > ・アルファベットキーに対しては大文字・小文字を無視する > > "L" → "<Shift>l" > > "l" → "l" > > <Control>j,<Control>J → <Control>j > > <Shift>space → <Shift>space > > 小文字であれば大丈夫です。 長々と説明しましたが、とりあえずこのように変更してみようと思いま す。また何か気付いたら言ってください。 ------------------------------- ヤマケン yamak****@bp*****
