Re: Possible UTF-8 CJK Regressions in Terminal Emulators

[Kenichi Handa]

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
changes.

---
Ken'ichi HANDA
address@hidden