Re: [PATCH] Unicode Lisp reader escapes

[Oliver Scholz]

Stefan Monnier <address@hidden> writes:

> I'm not sure I understand the nitpick:
[...]

That is entirely my mistake. It was late when I wrote the message and
my mind was occupied with utf-8 and `utf-fragment-on-decoding'. So I
misunderstood you as implying that ucs-table were encoded in UTF-8.

> I'm actually not sure if using emacs-mule instead of iso-2022 helps.
> It depends on whether or not unify-8859-on-decoding is also applied to
> emacs-mule "decoding".

It doesn't. decode_coding_emacs_mule in coding.c doesn't refer to
Vstandard_translation_table_for_decode at all, which would be
necessary for unification.

>> Though, the only way to deal with the latter would be to modify the
>> Lisp printer for writing *.elc files so that it escapes non-ascii
>> characters whereever possible with the new \u syntax. This would be
>> another solution to the problem we are discussing.]
>
> This would break the compilation of ucs-tables.el.

Ah, of course, I have not thought about that. Well, there would have
to be an exeption. I am not saying that this idea of mine is a good
idea, though, because I don't know how hairy it is to implement this.
IIRC `encode-char' and `decode-char' are not entirely symmetric, that
is, there are characters that `encode-char' can encode, but
`decode-char' can't encode. IIRC. But it would be the solution that
DTRT from the user's point of view. And it *could* be less hairy than
any of the other options discussed here, save "use emacs mule!" and
"warn/throw an error/document the problem", of course.


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