libiconvを通して楽しようかと思ったけど、なんか小回りが利かないように見える。
UTF-8→UCS-2の範囲でデコードして、そこからwchar16_tにデコードするテーブルを用意した方が良いんじゃないかなあ。UCS-4になるものは対応しない（〓にする）方針で。

テーブルの作成はlibiconvを使って、なんか適当にこしらえることにすれば良いかなと。

あまり頭の良い方法ではないのだけど、「とりあえず動かす」のにwchar16_tをごちゃごちゃ書き換えるのはかなり荷が重い。

なるほどね、wchar16_tだと、
0x00-0x7f : ASCIIと同じ
0x8ea1-0x8edf: 半角カナ
それ以外においては
(code & 0x0080) ? 普通のEUCコード : (SS3修飾されたもの & 0xff7f)
という手法で、16bitの範囲にEUC-JPを押し込んでる。

あと、eucmessages.c、現状のままだとデバッグが非常に困難になるからソースコードの文字コード(UTF-8)でメッセージを記述して内部ではEUC-JPにするとかいうのはどうなんでしょうかね。

というアイデアでどこまでやれるんだろうかー？

SJ_read()
current_locale == LC_TYPE_云々→io_locale == LC_TYPE_云々
UTF-8/EUC-JP/sjisに分けて処理
UTF-8の場合のみ、mbstowcs()の前にiconvでUTF-8→EUC-JP(mbs)変換

SJ_write(), SJ_print()
io_locale = UTF-8の場合のみ、wcstombs()の後にiconvでEUC-JP→UTF-8(mbs)変換

mbstowcs(), wcstombs()自体には手を入れない（影響範囲が広くなりすぎるため）

あとはwrite_stdout()の対応か。コードを見るに、1文字を構成するようなmulti-byte characterが揃うまで（という日本語で意味が通じるだろうか？）標準出力への対応を遅らせるというもののように見える。ここのIsknj2(), Isknj1()がEUC-JP向けなので、これはそのままになるんだろうけどUTF-8化にあたって何かケアが要るかもしれない（とはいえ、Shift-JISはそのままスルーになるのは何故）？

細かい問題が多少残ってはいるのだけど、現状のsj3(tty client)の作業は一旦ここで止めて、ブランチ切ってUTF-8化の検討に移ろうかなあ。何しろ画面に文字がちゃんと出ない方が面倒で…

なんとなくだけど、sj3捨ててkinput2とかuim越しにsj3serv使おうと言っている人達の気持ちは分かってきましたよー…

この辺の動作の詳細はstat_conv.cのstat_conv()に全部書かれてるな。
always_buffが真なら常にbufferモード（設定方法は後で調べないといけない）。
決定キー→unbufferに切り替え
変換キー→bufferに切り替え
半角決定キー(?)→unbufferに切り替え
という動作に見える。

やっぱそうだよなあ、stat_conv.cのChangeBuffMode()を見るに、buffer/unbufferの動作はトグルになってる。ということはbufferモード切替キーを押すごとにbuffer/unbufferが切り替わらないといけないんだけどそれ以前に.sjrcに.key.bufferの設定がコメントアウトされてる。（じゃあ何故全角かな入力モードにしたらbufferモードになったままになる？）

うえぇぇええ？（ktermだけCtrl-L時にステータスラインを保持、xterm, mlterm, rxvtは保持しない…というかrxvtはウィンドウサイズが取れないのかステータスラインの表示位置がおかしい）

sj3原典をVine 2.5上のktermで動かしちゃみたんだけど、Ctrl-Lで画面クリアしても一番下のステータス行はクリアされずに表示されてる。mltermだと消えてしまうので端末エミュレータの問題かも。

Bufferモードで、未確定文字列に対して適当にカーソルキーを叩いた場合の移動処理（とでもいうのかなあ）とそれに対する表示がなんかあってない感じはOpenBSD/amd64上での動作でもそうだったのでこれは元からアレだったっぽい。

ssh越しにsj3を起動して、未確定文字列がある状態でBSを叩くと確定してしまう（Ctrl-Hでは確定しない）というのはssh越しでの現象で、kterm上では起こらない。

うーむ、色々と怪しげな感じですなあ。