xterm + ibus-anthyなXIM入力
- U+FF5Eが入力される
firefox + ibus-anthyな入力
- U+FF5Eが入力される
kterm + ibus-anthyなXIM入力
- OverTheSpotで入力列を確定しても、shell promptに入力されない
- ；～；を確定するとshell promptに入力されるのは；；
kterm + copy&paste
- U+301C(WAVE DASH)及びU+FF5E(FULLWIDTH TILDE)をcopy&pasteで入力可能・表示グリフは異なるので別々の符号として扱われ、レンダリング時の内部処理でも別グリフとして扱われている
emacs + ibus-anthyなXIM入力
- OverTheSpotで入力列を確定しても、bufferに入力されない
- ；～；を確定するとbufferに入力されるのは；；

推論メモ

ibus-anthy側では、U+FF5E(FULLWIDTH TILDE)として扱われている (xterm XIM入力からの推論)
- 関係する textproc/ibus, japanese/ibus-anthy, japanese/anthy の中で、U+FF5Eはどのcomponent由来か？ (XIMが勝手に変換しているとは思えない)
utf8モードのktermは、copy&paste時はUTF-8を生のまま扱っているが、XIM入力はEUC-JP localeで受け取り内部でEUC-JP→UTF-8変換している (確認した実装)
- ibus側もしくはXIM層(Xserver or library)でUTF-8→EUC-JP変換時にU+FF5Eが無効符号として消滅している (仮説 1)
- 変なEUC符号位置に符号化されたU+FF5Eが、kterm側のEUC-JP→UTF-8変換でデコード出来ていない (仮説 2)
- 以前調査で使ったkterm用の入力検証パッチを当てて、XIMからの入力列を拾えば、消滅地点がXIM以前かkterm受け取り後か検証できるはず

別解

XIM入力をutf8モード以外で使う予定がなければ、XIM locale(eucJPLocaleリソース)をja_JP.UTF-8で初期化して、XIMからの入力を無変換で取り込めば動く？

~(U+007E)の全角対応の不一致問題

調査結果