[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
changes.
---
Ken'ichi HANDA
address@hidden
- Re: Possible UTF-8 CJK Regressions in Terminal Emulators,
Kenichi Handa <=
Re: Possible UTF-8 CJK Regressions in Terminal Emulators, Dave Love, 2004/06/08
Re: Possible UTF-8 CJK Regressions in Terminal Emulators, Kenichi Handa, 2004/06/11