Etsushi Kato
ekato****@ees*****
2004年 3月 21日 (日) 13:26:00 JST
ヤマケンさん、詳細な説明ありがとうございます。 uim は比較的最近さわったので、経緯など参考になります。 On Sun, Mar 21, 2004 at 06:55:03AM +0900, YamaKen <yamak****@bp*****> wrote: > ていました。これにより "Key_Return" のようなkeysymに反応して特別 > な処理(「Enterを押すと検索開始」等)を行うウィジェットでも期待通 > りの動作をするようにしていました。 なるほど、この点については気付いていませんでした。 > 現在のコードではskk-commit-newline-explicitly?が#tの状態でSEGVこ > そしなくなったようですが、以下のような問題のある挙動をします > (gtk-im-uimで確認)。 > > ▼とうきょうとちよだく【東京都▼千代田区】 > ↓ RET > ▼とうきょうとちよだく【東京都千代田区 > I】 確かにそうなりますね。登録時には、C-j を使うくせがついていたようで、こ の点も気付いていませんでした。 > このような状況なので、少なくとも今はまだ#fにしておくべきだと思い > ます。また、ウィジェット毎の特別な挙動の事を考えると将来もデフォ > ルトは#fであるべきだと思いますし、この設定項目自体無い方が良いと > 思います。C-mで改行を入力するようなカスタマイズはIM非アクティブ > 時にも有効になるようにツールキット側で行わないと意味が無いと思う > ので。 了解しました。デフォルト #f で OK です。 > ただ、後述のようにcommitとキーイベントの処理順を保証できないよう > な環境があるなら残しておく必要はあると思います。 > > > > ▽にほんご > > > > の状態で Enter キーを押した場合、im-uim なら #t でも #f でも期待どおり > > の挙動 （「にほんご」とその場で確定されて、カーソルは次の行に移る）を > > するのですが、uim-xim の場合、例えば rxvt 上で vim を使っている場合、 > > #f であると、確定された「にほんご」が次の行に来て、カーソルがその後ろ > > に位置してしまいます。また、#f の場合、確定したつもりの文字が消えてし > > まうこともあったのですが、ちょっと今は再現できません。#t なら期待どお > > りの挙動です。 > > これはuim-ximの問題ですね。commitとキーイベントの処理の順序が入 > れ換わってしまっているんだと思うんですが、uimから制御が戻ってき > た後にイベントキューが挟まっているようなので、この2つの操作の順 > 序を保証できるのか私にはちょっとわかりませんでした。Xの知識が無 > いもので。 uim-xim は難しいですね… 時間をとって少し調べてみます。 ありがとうございました。 -- Etsushi Kato ekato****@ees*****
