Re: [PATCH] Unicode Lisp reader escapes

[Oliver Scholz]

Richard Stallman <address@hidden> writes:

>     >> Here's one idea: if the -*- line specifies `coding' and specifies
>     >> the mode `emacs-lisp' then force unify-8859-on-decoding to nil
>     >> for that file.
>
>     Besides the work already mentioned, this would also require to turn
>     unify-8859-on-decoding-mode into a buffer-local minor mode.
>
> That is not the only possible implementation mechanism.  The commands
> that read and write the buffer could change it temporarily and change
> it back.
>
> However, it seems like a really bad thing to have a minor mode
> that CAN'T be buffer-local.  Why can't it be?  What is the difficulty?

Well, as already mentioned, unification and fragmentation are
implemented by means of translation tables. Unification, for instance,
for non-CCL decodings happens by means of modifying the parent of the
char table in the variable `standard-translation-table-for-decode'.
This is accessed as Vstandard_translation_table_for_decode in the
various decode_coding_XXX functions, for instance
decode_coding_iso2022, which affects many of the ISO 8859 coding
systems.

I have no idea whether it is simple to make this variable buffer local
or not. But, well, it's certainly intrusive to change such things at
the very heart and core of Emacs' decoding/encoding apparatus. (And
I'd like to second Kenichi Handa here: you'd might like to change to
Unicode Emacs *now* rather than making this kind of modification. The
Emacs Unicode branch is in sync with the current HEAD. Wielding out
the remaining coding issues means possibly possibly not much more work
and possibly *not* much more destabilizing than some of the
modifications we are discussing here.)

As for CCL-based coding systems, it is even a bit more difficult. CCL
coding systems do the translation table lookup in the CCL program
(with the CCL command `translate-character'). A named translation
table is *not* stored in a variable; it is stored in a
`translation-table' symbol property of the translation table's name.
The translation table relevant for unification in CCL decoding is
`ucs-translation-table-for-decode' (AFAICS only the cyrillic encodings
make use of this). The translation table relevant for fragmentation of
UCS coding systems is `utf-translation-table-for-decode'. You'd have
to find a way to make *that* buffer local.

As for being bad ... no, I don't think that it is bad that those minor
modes are global. They are a means to tune some details of Emacs'
internal handling of coding systems. *Internal* is the key point here.
It is nothing that conceptually relates to a particular file. (This
whole issue is something users should IMO not concern themselves with.
The benefit of changing the defaults is IMO dubious, anyways. I expect
that "unify on decoding of ISO 8859-*" and "fragmentation of UCS" will
mostly be abused for dealing with glyph issues -- i.e. something that
should be dealt with by adjusting the fontset.)

We are discussing a *very* special case here; it affects only Emacs
Lisp source files, because compilation of those, so to say, "freezes"
the particular settings for unification/fragmentation in the *.elc
file.


    Oliver
-- 
Oliver Scholz               27 Floréal an 214 de la Révolution
Ostendstr. 61               Liberté, Egalité, Fraternité!
60314 Frankfurt a. M.