Re: [PATCH] Unicode Lisp reader escapes

[Kenichi Handa]

In article <address@hidden>, Richard Stallman <address@hidden> writes:

> We seem to be talking about two variables here:
> unify-8859-on-decoding-mode and utf-fragment-on-decoding.

Their roles are as Eli wrote.

> Are there any others involved?

utf-translate-cjk-mode also plays a role on decoding utf-*.

> I do not know what those variables mean.  Do they affect the
> choice of coding system?  Or do they take effect by altering
> the meaning of a given coding system?

> If it is the former, the Lisp source file can defend against this
> problem by specifying coding in the -*- line.  We tell people to do this
> in Lisp source files.

> If it is the latter, there are two possible solutions:
> 1. to make the compiler bind these variables to their default values.
> 2. to tell people that all Lisp files for which this is relevant
>    should specify these variables explicitly.

The latter.

> If it is just those two variables, I think #1 is easy and preferable.

> Are there any other variables for which this arises?

Just setting those variables doesn't work; they should be
customized.  In addition, the default value of
utf-translate-cjk-mode t, and to which CJK charsets Han
characters of Unicode are decoded depends on these:

(1) current-language-environment

(2) utf-translate-cjk-unicode-range (which also
should be customized to take effect),

(3) utf-translate-cjk-charsets

(4) the contents of the hash table ucs-unicode-to-mule-cjk
(a user can freely reflect one's preference on how to decode
Unicode character by modifying this hash table).

---
Kenichi Handa
address@hidden