Re: [PATCH] Unicode Lisp reader escapes

[Kenichi Handa]

In article <address@hidden>, Richard Stallman <address@hidden> writes:

>> Are you talking about how the compiler would write the .elc file?
>> Or are you talking about how the .elc file would be interpreted?

>     It's the former. Meanwhile I have tested it. After some more thought I
>     think that the case of an UTF-8 encoded source files containing
>     characters from the Greek or Cyrillic repertoires is in fact entirely
>     analogous to what would happen with \u.

>     In other words: that particular bug is already there.

> Handa-san, could you please investigate the bug?
> Oliver, could you email Handa-san a description of the
> bug, in the form which already exists?  Can you find a test case
> which fails in the present development sources?

When you byte-compile a x.el file, x.el file is at first
decoded.  How x.el file is decoded depends on many thing,
and thus, of course, the resulting x.elc files become
different.  If you say that is a bug, I think there's no way
to fix it.

The very simple testcase is this:

(progn
  (let ((str "(setq x \"\300\300\")\n")
        (coding-system-for-write 'no-conversion))
    (write-region str nil "~/test1.el")
    (write-region str nil "~/test2.el"))
  (set-language-environment "Latin-1")
  (byte-compile-file "~/test1.el")
  (set-language-environment "Japanese")
  (byte-compile-file "~/test2.el"))

Although the source files are exactly the same, the
resulting test1.elc contains a string of two Latin-1
characters whereas the test2.elc contains a string of single
Japanese character.

I hope I misunderstand what you claim here.

---
Kenichi Handa
address@hidden