Re: [PATCH] Unicode Lisp reader escapes

[Oliver Scholz]

Aidan Kehoe <address@hidden> writes:

>  Ar an ceathrú lá de mí Bealtaine, scríobh Eli Zaretskii>: 

[...]
>  > What happens when a Lisp file is byte-compiled--do we want the result
>  > to depend on the local settings?

Oy! This might be a bit more serious than what I called a "minor
obscurity".

I guess, you have a similar problem when the source file is encoded in
either ISO 8859-5 or ISO 8859-7 (btw., what about Hewbrew, Arabic and
Thai?). Unless I am much mistaken, the encoding of the characters in
the .elc file would also depend on the value of
`utf-fragment-on-decoding'. A difference might be that this is much
more obvious in the case of a ISO 8859-[57] encoded file; and that it
is more obscure and more likely to cause puzzlement in the case of a
couple of letters specified with \u.

I have no opinion on how serious that is. One might say, that is just
one of the glitches of emacs-mule. Or maybe not. I don't know.

At least I don't see a proper solution to this.

> It does currently, to the extent of local settings preventing successful
> compilation. Cf. this code (on Unix):

[...]
>     (insert (concat
>            ";; -*- coding: utf-8 -*-\n\n"
>            "(require 'cl)\n\n"
>            "(defun describe-our-string ()\n"
>            "  (let ((our-char ?"
>            (format "%c%c%c" ?\345 ?\215 ?\227)
[...]
>   (utf-translate-cjk-mode 0)
[...]
>   (byte-compile-file our-test-file-name)
[...]

I am afraid that is not relevant here. This just tells Emacs to not
deal with UTF-8 encoded CJK characters and then tell it to deal with
such an character.


    Oliver
-- 
16 Floréal an 214 de la Révolution
Liberté, Egalité, Fraternité!