Re: [PATCH] Unicode Lisp reader escapes

[Eli Zaretskii]

> From: Aidan Kehoe <address@hidden>
> Date: Tue, 2 May 2006 12:59:43 +0200
> Cc: address@hidden
> 
>  > Whether it is safe or not, I think it's certainly better to implement
>  > the guts of decode-char in C, if it's gonna be called from
>  > read_escape. 
> 
> If it's only going to be called rarely (twice a file for non-byte-compiled
> files, at a liberal guess, never for byte-compiled files), and after
> decode-char is already loaded--both of which are the case--I don't see the
> argument for that.

And I don't see why we should assume anything for something as basic
as a subroutine of readevalloop.  It could be used to read anything,
not just .el files.

>  > Moreover, I think the fact that decode-char uses translation tables to
>  > support unify-8859-on-*coding-mode (and thus might produce characters
>  > other than mule-unicode-*) could even be a misfeature: do we really
>  > want read_escape to produce Unicode or non-Unicode characters when it
>  > sees \uNNNN, depending on the current user settings?
> 
> This is not significantly different from the question "do we really want
> (decode-char 'ucs #xABCD) to produce Unicode or non-Unicode characters
> depending on the current user settings?"

Maybe it's the same question, but since you are proposing to have
decode-char become part of routine reading of Lisp, this feature's
impact becomes much more important to discuss.

> since making string escapes inconsistent with the Unicode coding
> systems does not make any sense.

I'm not sure you are right; it should be discussed.

> And that question has already been answered. Cf.
> http://article.gmane.org/gmane.emacs.bugs/3422

Don't see any answers there about this, perhaps I'm too dumb.