GNU bug report logs - #4848
23.1.50; \u and \x in string

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: rms <at> gnu.org
Cc: 4848 <at> debbugs.gnu.org, emacs-pretest-bug <at> gnu.org
Subject: bug#4848: 23.1.50; \u and \x in string
Date: Tue, 03 Nov 2009 09:49:54 -0500

>> "\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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.