Mastodon の検索ボックスが動かなくなった件、どうも fcitx-skk を使用中に commit-unhandled 経由で流した \n コマンドが届いてないっぽいということがわかった (gnusocial (qvitter) の検索ボックスでも同様の問題が起きた)

fcitx-skk でなく fcitx での直接入力を使うとちゃんと Enter イベントが通るので、不思議

javascript 経由で何かあると駄目なのかなと思っている

普通の1行ボックス (github の検索とか)は Enter そのまま通るので

SKK は英字入力もそのままできるせいで常時 SKK 有効化していたんだけど、さすがにこのレベルの (xim レイヤーの)バグを直す知識はないので、入力メソッド OFF のホットキーを用意することで運用で対処しようと思う

今のところ C-j と Muhenkan を入力メソッド有効化に割り当ててるので、 C-S-j と Shift-Muhenkan を入力メソッド無効化に割り当てた

分析と思い付き #らりおメモ #らりおメモTODO

事実:
Enter のみならず、上下キー等も反応しない場合がある。
javascript 使ってるらしき場合特にそうで、典型的には google のサジェストとか Mastodon / gnusocial (qvitter) の検索ボックスなど。

これらは fcitx の直接入力自体ではうまくハンドルされているので、 fcitx-skk か libskk が良くない処理をしていることを疑うべきである。

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" ルールが使われるように見える。