Re: Possible UTF-8 CJK Regressions in Terminal Emulators

[Kenichi Handa <handa@m17n.org>]

In article <rzqd64agch6.fsf@albion.dl.ac.uk>, Dave Love <d.love@dl.ac.uk> writes:

> Kenichi Handa <handa@m17n.org> writes:
> > 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.

> It doesn't fix the potential effects on non-CJK users if decoding a
> bit of Unicode text containing such a character will load the large
> tables even if they're useless to the user.  Maybe there aren't many
> people now with 48MB P133s or old SPARCs like me, in which case it's a
> reasonable default, but I suggest an entry in NEWS/PROBLEMS about it.

I'm going to modify the current entry in NEWS as below.

** The utf-8/16 coding systems have been enhanced.
By default, untranslatable utf-8 sequences are simply composed into
single quasi-characters.  User option `utf-translate-cjk-mode' (it is
turned on by default) arranges to translate many utf-8 CJK character
sequences into real Emacs characters in a similar way to the Mule-UCS
system.  As this loads a fairly big data on demand, people who are not
interested in CJK characters may want to customize it to nil.  You can
augment/amend the CJK translation via hash tables
`ucs-mule-cjk-to-unicode' and `ucs-unicode-to-mule-cjk'.  The utf-8
coding systems now also encodes characters from most of Emacs's
one-dimensional internal charsets, specifically the ISO-8859 ones.
The utf-16 coding system is affected similarly.

> > I think it's a big improvement especially for CJK users,

> I agree it should be on for CJK users anyway.  (I thought it was now
> conditional on the language environment.)

It's not.  I think we had better avoid turning on/off a user
option depending on language environment.

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