Re: [Mlterm-dev-ja] =?ISO-2022-JP?B?GyRCJW0lMSE8JWskSBsoQm1sdGVy?= =?ISO-2022-JP?B?bRskQiROJSglcyUzITwlRyUjJXMlMCQsMGMkJj5sOWckTkZ+Tk8bKEI=?=

[Tomohiro K. <tk...@ri...>]

久保田です。

At Tue, 11 Dec 2001 23:04:00 +0900 (JST),
sakamoto hironori wrote:

> > 3. Xutf8LookupString() を使う。
> >    ぼくはこれがいちばんきれいな解のように思えます。CJK Han Unification
> >    などに原理的に対応できなくなりますが、どうせ現状でも対応できている
> 
> XFree86 と、そうでない X とで動作が変わってしまいますよ。
> # XFree86 の xterm のコードを使えばいいのかもしれませんが。

それは、その通りです。この案の欠点です。XFree86 の XTerm のコードを
使ったところで、Xutf8LookupString() がない環境では機能が制限されて
しまいます。

# XTerm の実装では、Xutf8LookupString() がない環境では Latin-1 しか
# 入力できません。ですので、Xutf8LookupString() がない環境では
# mlterm の現状を使うというふうにするのがいいと思います。


> それに根本的な解決にはなりません。
> # それこそ X<encoding>LookupString() が必要になるかと。
> # パーサはあるから出来そうな気もする。

これもその通りで、mlterm はパーサを自前で持つソフトウェアつまり
Code Set Independent ではないソフトウェアなので、そのパーサの性能と
見比べながら Xutf8LookupString() を使っても構わないということになる
と思います。Xutf8LookupString() を嫌う理由としては、CSI ではない、
ということだと思うのですが、どうせ mlterm はもとから CSI ではない
のですから。(もうひとつ、Unicode のサブセットでないエンコーディングが
ロケールでサポートされていたときに機能が劣るという問題がありますが、
Unicode のサブセットでないエンコーディング [ISO-2022-JP-2 とか
TRON コードとか] がロケールでサポートされている実例って、ぼくは
ひとつも知りません)。

# CSI では、ロケールとエンコーディングは絶対に一致しなければ
# なりませんね。

> >    OS などありませんし (つまり、XmbLookupString() を使うことで、
> >    CJK の漢字を使い分けることが可能な OS ってないでしょう、ということ)。
> 
> これはどういうことでしょうか？
> ISO-2022-JP-2 を使えば使い分けることが出来そうですが。

そうですが、それを実装した実例がないなら、存在しないものへの対応を
謳うことにどれだけの意味があるのか、ということです。それと比べて、
ロケールと mlterm のエンコーディングが一致しないとき、XIM を使わない
言語 (CJK 以外ぜんぶ) が入力できないという問題の解決と、どちらを
優先させるのがいいか、という価値観の問題です。ぼくとしては、仮想的な
問題よりは、現実に存在する問題のほうを優先させたいと思います。
もちろん、この問題を解決できるなら、Xutf8LookupString() の使用に
こだわるつもりはありませんが、どんな解決策があるでしょうか?

> とりあえず、
> ISO-2022-* の様にロケールには無いエンコーディングもありますし、
> ロケールとエンコーディングは切り離して考えた方がいいと思います。
> 入力できないからって表示すら使えなくなるのは困る。

そうですね。だから、ぼくの (1) の案は却下ということで。なにか
対案はありますか?

---
久保田智広 Tomohiro KUBOTA <ku...@de...>
http://www.debian.or.jp/~kubota/
"Introduction to I18N"  http://www.debian.org/doc/manuals/intro-i18n/