Re: [PATCH] Unicode Lisp reader escapes

[Oliver Scholz]

Richard Stallman <address@hidden> writes:

>     > Add a new "variable" `buffer-coding' which is analogous to `coding'.
>     > Whereas `coding' specifies the encoding in the file, `buffer-coding'
>     > specifies the in-buffer encoding to produce in the buffer.  Its value
>     > could be a list or plist, which would specify the values of all these
>     > many variables.
>
>     > What do you think?  If you think this is a good idea, could
>     > you try designing the details?
>
>     No, it's an incredibly hard and heavy task.
>
> I am surprised you think so, and this means there is some sort of
> misunderstanding between us.
>
> You've listed around 6 variables that affect the decoding.  So it
> seems to me that if we make a convenient way for each Lisp file to
> specify those 6 variables, we solve the problem.  It looks easy to me.

Yes, I think there is a misunderstanding. It is not the value of those
variables that affects decoding. But changing the value of those
variables via their corresponding minor mode functions or via
customize initialises translation tables (char tables and arrays) and
in some cases adjusts codings systems to use those tables. See
`ucs-unify-8859' and its counterpart `ucs-fragment-8859' for an
example. In most, if not all affected cases, binding variables to
another value would have no effect whatsoever. In some cases like
`utf-fragment-on-decoding' you'd first have to write functions to
programmatically cause the associated effect.

In fact, it might be easier (and even safer) to just change the
encoding of *.elc files from emacs-mule to utf-8.

Then there may be possible consecutive problems. For instance,
Handa-san mentioned an example of how a user could have reason to
modify the affected translation tables. Are users supposed to do that?
(I'd argue, they should rather change the fontset.) If yes, you'd need
to make sure that such changes are preserved after swapping and/or
redefining all those translation tables during byte compilation. Maybe
they are anyways, but we are talking about a lot of mule code here.

Finally, users might encounter *either* behaviour in a way that makes
them think it is a bug. If byte compilation is modified the way you
propose, then what some users will probably just see is that the
glyphs of some characters coming from a byte compiled file differ from
what they specified in their .emacs. That will come as a surprise to
them and investigating it is not exactly easy, if you are not familiar
with Emacs' internal handling of characters. So it might be a good
idea to document even the fix of the bug we are discussing in
etc/PROBLEMS, because it *is* a design problem of `emacs-mule'.

(And as Handa-san mentioned, things like that are the actual reason
that changing the internal encoding to UTF-8 is a worthwile enterprise
in the first place.)


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