Re: [Mlterm-dev-ja] commig log

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

久保田です。

すみません、理解力がなくて、何度も質問してばっかりですが。

At 16 Dec 2001 18:45:00 +0900,
Araki Ken wrote:

> まず、-c(xct_process_mode) オプションの意味を変えました。
> 
> -c=ucs: 受け取った ctext を ucs に変換します。(旧来の pre_conv_xct_to_ucs 相当)
> -c=raw: 受け取った ctext をそのまま pty に流します。(旧来の conv_to_generic_iso2022 相当)
>         ただし、端末エンコーディングが、ISO2022 準拠な場合にしか有効になりません。
> -c=normal: 受け取った ctext を 端末エンコーディングに変換します。(従来の通常動作)

すみません、まだよくわからないんですが、ctext を受け取るというのは、
mlterm へのペースト時ですよね。ふつう、そういう場合、どんな時でも
必ず端末のエンコーディングに変換しないといけないのではないのですか?
(つまり、そうしないと正常に動作しない)。

-c=ucs というのが、pre_conv_xct_to_ucs ということは、ctext を
受け取ったとき、いったん UCS に変換してから端末エンコーディング
へと 2 段階に変換する、ということですね? (つまり、UCS に変換して
そのまま、ということはないですよね?) これの使い道としては、別の
文字セットに属するけれども Unicode では同一視されている文字を、
同一視することができる、ということですよね。(たとえば、ISO-8859-1
と ISO-8859-2 は多くの共通の文字がありますし、Han Unification も
その対象になりますね。)

-c=raw というのは、どういうときに使うのでしょうか? つまり、端末の
エンコーディングとは違うもの (CTEXT) が、端末に対して送られる、
ということですよね。これは正常に動作しないのではないですか? また、
ctext 以外のペースト (たとえば utf8 とか) を受け取ったときには、
どうなるのでしょうか。

(ISO2022 準拠というのは、たとえば Big5 や GBK や KOI8-R は
ISO2022 準拠ではないけど、EUC-JP や TIS-620 は ISO2022 準拠だ、
ということですよね?)


> また、prefer_utf8_selection=true しただけでは、受け取った CTEXT を ucs
> に変換しないようになっています。

つまり、ペーストを受けた mlterm がペースト元に対して UTF8 な
selection を要求したにもかかわらず、CTEXT が返ってきた場合、
ということですね。

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