Re: Possible UTF-8 CJK Regressions in Terminal Emulators

[Kenichi Handa <handa@m17n.org>]

In article <rzqvfl2yxsg.fsf@albion.dl.ac.uk>, Dave Love <d.love@dl.ac.uk> writes:
>>  Change utf-translate-cjk-mode to a customizable variable
>>  utf-translate-cjk which is nil, t, or auto (default).  The
>>  values nil and t mean the same thing as the current value of
>>  utf-translate-cjk-mode.  The value `auto' means setting up
>>  tables for translating CJK characters automatically if
>>  necessary.
>> 
>>  By adding pre-write-conversion function, we can make the
>>  above work also on writing.  But, in that case, it seems
>>  difficult to make find-coding-systems-region/string work
>>  consistently.  To check if a text is encodable by utf-8, we
>>  must load translation tables.

> As far as I remember, that's why I didn't implement that sort of
> thing.

Wait!  If utf-translate-cjk-mode can encode all jis, kcs,
big5, and gb to utf-8, we can tell that they can be encoded
by utf-8 without loading tables.  What we have to do is to
simply include those charsets in `safe-charsets' on defining
utf-8.

> post-read-conversion machinery is already there, I think.

Yes, utf-8 already has utf-8-post-read-conversion which
composes unencoded raw-bytes into Unicode U+FFFD.

> [Is this code base ever going to be released so that most users
> actually can use it?]

I'd like to ask it too.

---
Ken'ichi HANDA
handa@m17n.org