分析と思い付き #らりおメモ #らりおメモTODO
fcitx-skk で処理しているのは
https://github.com/fcitx/fcitx-skk/blob/abedca1fd37cf47a462d728b2afca514d708e05c/src/skk.c#L556-L566
この部分で、たとえば commit-unhandled 等でパススルーされたキーイベントは process_key_event() が false を返すから、 IRV_TO_PROCESS で fcitx-skk (fcitx) が処理せずイベントを素通しすることになる。
つまり、 fcitx-skk 自体は妥当なことをしているように思われる。
さて libskk の該当部分はこれ
https://github.com/ueno/libskk/blob/master/libskk/context.vala#L499-L511
で、フィルタを素通りしたキーイベントについて、モード等に応じて適当なイベントハンドラを呼び出す形になっている。
process_key_event_internal は最近読んでいたし基本的には該当のモード (state) のハンドラに丸投げするだけなので、 filter_key_event を疑ってみる。
https://github.com/ueno/libskk/blob/master/libskk/context.vala#L203-L207
デフォルトのフィルタは state スタックの一番上から持ってきているが、デフォルト(スタックの一番底)は
https://github.com/ueno/libskk/blob/master/libskk/context.vala#L230
このように設定されている。
State の初期値はあまり関係なかったわ……
https://github.com/ueno/libskk/blob/d5df1624942f97d39ca8f76102e56ee4d6a7302d/libskk/context.vala#L203-L207
フィルタは typing_rule として保持されているから、 Rule の該当処理のデフォルトを見る。
https://github.com/ueno/libskk/blob/d5df1624942f97d39ca8f76102e56ee4d6a7302d/libskk/rule.vala#L170-L181
この辺でデフォルト設定の候補というかプリセットみたいなのを用意して、
https://github.com/ueno/libskk/blob/d5df1624942f97d39ca8f76102e56ee4d6a7302d/libskk/rule.vala#L216-L227
ここで処理。
フィルタが明示的に用意されなければ、 "simple" ルールが使われるように見える。
これは明らかに怪しい。
javascript での入力ハンドリングにリリースイベントを使っているとしたら、 libskk 側でそれが握り潰されていることが考えられそうだ。
Let key release events pass through by lo48576 · Pull Request #52 · ueno/libskk
https://github.com/ueno/libskk/pull/52
結局完璧な方法が思い付かなかったのでかなり妥協して、リリースイベントを全て素通しさせることにしました。
このパッチを使えば、 google のサジェストでの上下キーや Mastodon の検索ボックスでの Enter キーなどが正しく動きます
https://github.com/ueno/libskk/blob/d5df1624942f97d39ca8f76102e56ee4d6a7302d/libskk/context.vala#L507-L509
リリースイベントが無視されて null が返却されると、 process_key_event() 自体は true を返す。これはイベントが libskk によって消費されたことを意味しており、結果 fcitx-skk から元のアプリケーションにイベントが伝達されることはない。