[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Possible UTF-8 CJK Regressions in Terminal Emulators

From: Kenichi Handa
Subject: Re: Possible UTF-8 CJK Regressions in Terminal Emulators
Date: Mon, 7 Jun 2004 21:27:36 +0900 (JST)
User-agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.3 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI)

While fixing a bug of utf-8-post-read-conversion (it may
modify a text out of range), I remembered this discussion,
and did some work.

In article <address@hidden>, Kenichi Handa <address@hidden> writes:

> In article <address@hidden>, Dave Love
> <address@hidden> writes:
>>  Kenichi Handa <address@hidden> writes:
>>>   Wait!  If utf-translate-cjk-mode can encode all jis,
>>> kcs, big5, and gb to utf-8,

>>  I don't think that's true (or I think it wasn't when I
>> built the tables).  Maybe that's not so (now).  Also, the
>> tables are customizable by design -- for instance, I
>> anticipated people adding characters from CNS.

> I've just checked all subst-*.el.  They all contain full
> maps, i.e. all defined characters can be encoded into
> utf-8.  Of course, a character not defined in each
> standard (e.g.  a character made by (make-char
> japanese-jisx0208 37 126)) can't be encoded, but I think
> the merit of ignoring such a character is higher than
> correctly telling that they can't be encoded into utf-8.

I think I succeeded in loading subst-*.el not at the time of
customizing utf-translate-cjk-mode to t but only when it is
found that loading them is necessary on decoding or encoding
utf-8, or on running decode/encode-char.  This means that we
can make the default value of utf-translate-cjk-mode to t
without loading subst-*.el at building time.

I think it's a big improvement especially for CJK users, and
is an improvement of an existing feature rather than a new
feature.  If people agree on making utf-translate-cjk-mode
to t, I'll brush-up the current working code and install the

Ken'ichi HANDA

reply via email to

[Prev in Thread] Current Thread [Next in Thread]