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上では起こらない。

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

Fediverse内でも #鉄塔 とか #送電鉄塔 クラスタってあるんでしょうか。あるといいな。

都留線242号と橋本西線20号。

（Twitter側でも呟いてますが）小倉開閉所に来る路線、都留線の他に橋本西線、東海小倉線になりそうです。

@osapon 自分の感覚だと、旧→新でトゥートを並べるなら継ぎ足しは未来のものが表示された方が良いのではと考えていますが、確かに逆方向の継ぎ足しはどうするのという問題はあります（AutoPagerizeはそういう機能は持っていないようですが、今後そういうものが出てくる可能性もあるかもしれませんし…）。

こちらが恐れているのは、常に過去を継ぎ足す動作に固定することで、notestockで旧→新並びの設定を行っている人達がSITEINFOを書き換えてしまい、新→旧並びの人達と対立することです（notestockのデフォルトが旧→新並びとなっているから、というのもあります）。

SITEINFO側ではこれに対して柔軟な対応ができない以上、notestock側でお願いしたいというところはあるのですが…「SITEINFOは新→旧で使うことが前提です」と突き放すコメントを出すことも案としては持っています。