bug-gnu-emacs
[Top][All Lists]

## bug#4848: 23.1.50; \u and \x in string

 From: Stefan Monnier Subject: bug#4848: 23.1.50; \u and \x in string Date: Tue, 03 Nov 2009 09:49:54 -0500 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

>> "\ue1" gives the error "Non-hex digit used for Unicode escape".
>> Why doesn't it work to give the Unicode character Ã¡?
>     I think you mean \u00e1
> Why shouldn't \ue1 work?

Because the \u format is \uNNNN with exactly 4 hex digits.

>> Note that \xe1 does not work for this any more.
>     Indeed, this refers to the byte 225 rather than to the char 225.
> This needs to be documented.  But is it a good meaning for \x?  It
> will rarely be useful this way.  Also, is it an incompatible change?

I haven't managed to keep track of all the changes w.r.t how we treat
\NNN vs \xMM vs \xMMMMM and how it impacts whether the resulting string
is unibyte or multibyte.  My understanding is that there have been
several incompatible changes in this area (and some of those were
inevitable).  E.g. in Emacs-22:

ELISP> "\222"
"\222"
ELISP> "\xa4"
"\xa4"
ELISP> (multibyte-string-p "\222")
nil
ELISP> (multibyte-string-p "\xa4")
t
ELISP> (multibyte-string-p "\xa45")
t
ELISP>

whereas in Emacs-23.1:

ELISP> "\222"
"\222"
ELISP> "\xa4"
"\244"
ELISP> (multibyte-string-p "\222")
nil
ELISP> (multibyte-string-p "\xa4")
nil
ELISP> (multibyte-string-p "\xa45")
t
ELISP>

Of course, given that fact that char-numbers have changed, the
backward compatibility of \xNNNN is irrelevant since they do not
represent the same char any more.

Stefan