Masanari Yamamoto
h0131****@ice*****
2005年 12月 24日 (土) 13:20:53 JST
On Sat, Dec 24, 2005 at 12:15:21PM +0900, YamaKen wrote: > At Sat, 24 Dec 2005 09:15:37 +0900, > h0131****@ice***** wrote: > > On Sat, Dec 24, 2005 at 02:09:24AM +0900, YamaKen wrote: > > > 「IMをoffにしようとする」というのは具体的には何を行うんでしょう? > > > contextをresetするとか? > > > > gvim側からIMをoffにしようとするとき > > gtk_im_context_reset(xic); > > gtk_im_context_set_use_preedit(xic, FALSE); > > gtk_im_context_set_use_preedit(xic, TRUE); > > これらの関数呼び出しを行います。im-ximの場合、下2つの関数でIMがoffにな > > ります。 > > なるほど。下2つの呼び出しでIMのon/off状態がresetされる事を仮定し > てるわけですね。 基本的にはgtk_im_context_resetでoffになることを期待していて、 gtk_im_context_set_use_preeditを2回呼ぶのはAmi用でAmiはこれによって offになるそうです。 > > > 今後のuimの方向性からしてそれは受け入れ難いです。ブリッジがIMの > > > 内部状態を関知するのは責任分離上好ましくないです。 > > > > では、アプリ側からIMのon/offを制御することはできないということでしょう > > か。 > > ここまでの話ではアプリ側から明示的にdirect IMへの切り換えを指示 > するのが現在のuim的には正しいように思います。インタフェイスの問 > 題を無視すれば。これ以外の手段ではASCII以外の文字が入力されない > 事を完全には保証できません(= IMの実装次第でgvimがおかしな状態に > なり得る)。 > > というか、このケースではgvim的にはimmoduleレベルでoffにするか > direct IM相当のIMに切り換えるのが正しいような気がしますが、そう > いう手段はないんでしたっけ? IMの切り替えはAPIがなくてメニューでしか切り替えれないとここには書いて あります。 http://homepage1.nifty.com/iwamotokazuki/gtkim/GTKIM05.TXT > > > まだよく仕様がわかってないんですが、insert mode時にpreedit_start > > > とpreedit_endが何回も発生するとまずいんでしょうか。また、現状の > > > コードでもnormal modeに遷移する前には必ずpreedit_endが発行済の状 > > > 態になっているはずですが、正確にinsert→normalの遷移のタイミング > > > で発行されないとまずいんでしょうか。 > > > > preedit_startが発生するとim_is_activeという変数がTRUEになって、 > > preedit_endが発生するとim_is_activeがFALSEになります。 > > uimはsnooperを使っているから関係ないのですが、im_is_activeがTRUEのと > > きしかIMにキーイベントが送られません。 > > IMをonにするためのキーはgvimが知っていて(imactivatekeyオプションで設定 > > します)、そのキーだけはim_is_activeがFALSEのときでもIMに送られます。 > > また、im_is_activeがTRUEのときはカーソルの色が変化してユーザにIMがonで > > あることがわかるようになります。 > > なるほど。では現状の問題点は、 > > 1. gvimはIMにon/off状態がある事を知っていて(仮定していて) > 2. その状態を表示するための独自のインジケータを持っている > 3. そしてpreeditのあり/なしがIMのon/offに同期すると仮定している > 4. したがってカーソルの色が不要に変化してしまう > > という事ですね。 > > ブリッジ本体の動作がIMの内部状態に感応するのは避けたいですが、イ > ンジケータの制御として分離できるならOKです。 > > 将来インジケータのためのインタフェイスが標準化されたらモード表示 > 用のインジケータが'mode_directかどうかに対応付ける事はできると思 > うし現状でも不完全ながらmode APIを使って検出できますが、問題は通 > 知手段ですね。 > > クライアントがgvimの場合のみの特別扱いとしてコードをある程度分離 > できるなら(できれば別ファイル)、gvim専用にpreedit_start/endのフィ > ルタを作ってもよいと思います。もっと良い手段が見つかったら乗り換 > えるという事で。 immodule側からクライアントが何であるかってわからないですよね? uim-prefで設定するなら可能ですが。 もしgvimの場合を特別扱いできるなら、key snooperも使わないようにしたい です。 key snooperを使うか使わないかはuim-prefで設定できてもよいと思います。 > このへんの対応はcomposerフレームワークが導入されたらvi-adapterと > してuim内に移動しようと思うので、それまで待てるなら今は見送ると > いう手もありだと思います。今回の件を考慮して空のpreeditとpreedit > なしの状態をcomposerのレベルで区別できるようにしようと思います。 今はカーソルの色の変わるタイミングがおかしいというだけで、使えないとい うこともないのでこのままでもいいと思います。 カーソルの色もこの設定をしなければ変わらないですし。 highlight CursorIM guibg=Purple guifg=NONE -- 山本将也
