ISO-2022 準拠ではないエンコーディングを使っている人は、それを ISO-2022 で切り替えて使いたいという要求を持っていないはずですから、べつに final character を定義する必要もないと思います。ISO-2022 のエスケープシーケンスで切り替えることができる範囲は、ISO-2022 で使うことができる文字集合だけでいいと思います。
こうすることで、たとえ iconv に新しいエンコーディングが追加されても、jfbterm には何ら変更を加えることなくサポートできますし、設定ファイルの巨大化も防げます。ユーザに設定ファイルを書くという負担を与えなくてすみますし※、設定ファイルの typo の心配もなくなります。で、その場合、そのままだと jfbterm --reset が動かなくなってしまいますが、それはそれでいいと思います。それじゃまずい場合は、mlterm で用いられている ESC ] 5 3 7 9 ; e n c o d i n g = encoding BEL というコードを使うのはいかがでしょうか。パーサを書くのが面倒そうですが。
/usr/share/i18n/SUPPORTEDのサポート (スコア:2, 参考になる)
other coding system は設定ファイルに書かなくても動かすことは できます。例えば
jfbterm -c other,SHIFT_JIS,iconv,EUC-JPで EUC-JPと同じフォントを使って SHIFT_JISの表示とかができるはずです。
ただし、final characterはhard codingしてなくて設定ファイルでしか 設定できないので、いったん ESC 2/5 4/0 とか ESC 2/5 4/7 とかで ISO-2022 や UTF-8 にいってしまうと戻ってくることができません。
現在は ESC 2/5 F にしてますが なんか intermediate character を使う ように ESC 2/5 2/? F とかにした方がいいかもしれません。
/usr/share/i18n/SUPPORTED に載ってるやつは網羅しておきたいということなので ちょいと現状をまとめてみました。 http://ukai.org/wiliki/wiliki.cgi?Software%3ajfbterm&l=jp [ukai.org]
?? のあたりすぐわかるようならば埋めていってください。
このあたりの調整は設定ファイル次第でなんとかなるかも。
非ISO-2022エンコーディングの扱い (スコア:2, 興味深い)
-c に未知な文字列が指定された場合、または、nl_langinfo() が未知な文字列を返してきた場合、それは iconv_open への引数として扱うというのがいいと思います。また、ISO-2022 で定義され、設定ファイルにも記述がある場合であっても、もしその文字集合のフォントがなければ UTF-8 経由で iconv を使うようにする、というのがいいかもしれません。
というか、その場合、わざわざ設定ファイルで Shift_JIS とか Big5 とかを定義する必要もないと思います。いまのところ、どうしても設定ファイルでしか決定できないことといえば、final character だけですから。むしろ、CJK 以外は原則そのモード (iconv を使って UTF-8 経由) で動かす (つまり、設定ファイルから削除する) のも手かも。
こうすることで、たとえ iconv に新しいエンコーディングが追加されても、jfbterm には何ら変更を加えることなくサポートできますし、設定ファイルの巨大化も防げます。ユーザに設定ファイルを書くという負担を与えなくてすみますし※、設定ファイルの typo の心配もなくなります。で、その場合、そのままだと jfbterm --reset が動かなくなってしまいますが、それはそれでいいと思います。それじゃまずい場合は、mlterm で用いられている ESC ] 5 3 7 9 ; e n c o d i n g = encoding BEL というコードを使うのはいかがでしょうか。パーサを書くのが面倒そうですが。
※ ぼくが国際化にとりくみはじめたきっかけは、日本語を扱うためだけになぜ、それだけで本が1冊書けるようなくらい大量の煩雑な設定をしなきゃならないのだ、ということです。それを解消するには、設定のうち、本来不要であるべきものを、ひとつひとつつぶしていくよりほかありません。ですので、ほかの言語に対しても、「ひとつくらい、いいじゃん」というふうな気持ちで設定作業を要求するのは、いやなのです。