[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: |
Wed, 9 Jun 2004 16:24:13 +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) |
In article <address@hidden>, Dave Love <address@hidden> writes:
> Kenichi Handa <address@hidden> 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
address@hidden
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 <=
Re: Possible UTF-8 CJK Regressions in Terminal Emulators, Kenichi Handa, 2004/06/11