Re: [PATCH] Unicode Lisp reader escapes

[Richard Stallman <rms@gnu.org>]

The C code you wrote to implement byte-compile-no-char-translation
might be the right C-level feature.  We need Handa to check that, as
you said.

It should only affect unify-8859-on-decoding-mode, since that's the
only one that's relevant to iso-2022.  (We decided to give up on
stabilizing utf-8 in this way, because too many different variables
affect the behavior of utf-8.)

However, the right place to set the variable is in find-auto-coding,
not in the compiler.  Therefore, the variable's name should be
changed, since it won't be specific to compilation.  It could be
stabilize-iso-2022.

I can see three possible ways for Lisp files to set this variable:

1. Explicitly.  You should specify the variable in the -*- line or the
Local Variables list if it matters.

2. Automatically.  Whenever a file specifies Emacs-Lisp mode and
coding iso-2022, it gets set to t.

3. Both.  It gets set to t automatically, but a file can explicitly
specify nil.

I have another, further suggestion.  Rename the variable to
unify-8859-on-decoding-mode, and reimplement the function
unify-8859-on-decoding-mode to work just by setting the variable.
That would be an improvement, since it would mean you can set the mode
just by setting the variable.