Unicode character read representation

Unicode character read representation

[Chong Yidong]

From objects.texi in the Lisp manual:

  `\U00NNNNNN' represents the character whose Unicode code point is
  `U+NNNNNN', if such a character is supported by Emacs.  If the
  corresponding character is not supported, Emacs signals an error.

Are there any Unicode code points not supported by Emacs, or is this
sentence obsolete?

Re: Unicode character read representation

[Harald Hanche-Olsen]

+ Chong Yidong <cyd@stupidchicken.com>:

> From objects.texi in the Lisp manual:
> 
>   `\U00NNNNNN' represents the character whose Unicode code point is
>   `U+NNNNNN', if such a character is supported by Emacs.  If the
>   corresponding character is not supported, Emacs signals an error.
> 
> Are there any Unicode code points not supported by Emacs, or is this
> sentence obsolete?

I don't know the answer to your question, but it appears to me that
some code points SHOULD not be supported. The most famous example
being U+FFFE, which is why U+FEFF ZERO WIDTH NO-BREAK SPACE is useful
as a byte-order mark. (But Emacs reads "\0000FFFE" just fine. A bug?)

- Harald

Re: Unicode character read representation

[Kenichi Handa]

In article <87hc2n28a4.fsf@cyd.mit.edu>, Chong Yidong <cyd@stupidchicken.com> writes:

> From objects.texi in the Lisp manual:
>   `\U00NNNNNN' represents the character whose Unicode code point is
>   `U+NNNNNN', if such a character is supported by Emacs.  If the
>   corresponding character is not supported, Emacs signals an error.

> Are there any Unicode code points not supported by Emacs,

No.

> or is this sentence obsolete?

Not completely obsolete, but should be modified somehow.

At first, #x0..#x3FFFFF are all valid Emacs character codes.

Some of U+NNNNNN are valid Unicode code points for
"noncharacter" (e.g. U+FFFE, U+FFFF), some are invalid
Unicode code points (U+120000..U+3FFFFF), some are invalid
both as Unicode code points and Emacs character codes
(U+400000 and over).

Currently Emacs signals an error only for U+400000 and over,
and I'm not sure how strictly we should interprete
\U.. notation.

---
Kenichi Handa
handa@m17n.org

Re: Unicode character read representation

[Stefan Monnier]

> Currently Emacs signals an error only for U+400000 and over,
> and I'm not sure how strictly we should interprete
> \U.. notation.

I think the \U notation should only work for actual unicode chars.
(assuming the \x{..} notation can be used for everything else).


        Stefan

Re: Unicode character read representation

[Kenichi Handa]

In article <jwvprh7qy68.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > Currently Emacs signals an error only for U+400000 and over,
> > and I'm not sure how strictly we should interprete
> > \U.. notation.

> I think the \U notation should only work for actual unicode chars.
> (assuming the \x{..} notation can be used for everything else).

For instance 0xFFFF is a valid Unicode code-point, but is
not a character.  Should it be accepted or not?

---
Kenichi Handa
handa@m17n.org

Re: Unicode character read representation

[Stefan Monnier]

>> > Currently Emacs signals an error only for U+400000 and over,
>> > and I'm not sure how strictly we should interprete
>> > \U.. notation.

>> I think the \U notation should only work for actual unicode chars.
>> (assuming the \x{..} notation can be used for everything else).

> For instance 0xFFFF is a valid Unicode code-point, but is
> not a character.  Should it be accepted or not?

Yes, it should.  But I think that \u3FFFFF shouldn't since it's not
a valid unicode code point.


        Stefan

Re: Unicode character read representation

[Kenichi Handa]

In article <jwvzlg9dyo4.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > For instance 0xFFFF is a valid Unicode code-point, but is
> > not a character.  Should it be accepted or not?

> Yes, it should.  But I think that \u3FFFFF shouldn't since it's not
> a valid unicode code point.

Ok, I've just installed this change.

Index: lread.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/lread.c,v
retrieving revision 1.403
retrieving revision 1.404
diff -u -r1.403 -r1.404
--- lread.c	25 Feb 2009 12:47:24 -0000	1.403
+++ lread.c	27 Feb 2009 00:48:03 -0000	1.404
@@ -2205,7 +2205,7 @@
       /* A Unicode escape. We only permit them in strings and characters,
 	 not arbitrarily in the source code, as in some other languages.  */
       {
-	int i = 0;
+	unsigned int i = 0;
 	int count = 0;
 
 	while (++count <= unicode_hex_count)
@@ -2222,7 +2222,8 @@
 		break;
 	      }
 	  }
-
+	if (i > 0x10FFFF)
+	  error ("Non-Unicode character: 0x%x", i);
 	return i;
       }
 
---
Kenichi Handa
handa@m17n.org

Re: Unicode character read representation

[Chong Yidong]

Kenichi Handa <handa@m17n.org> writes:

>> Yes, it should.  But I think that \u3FFFFF shouldn't since it's not
>> a valid unicode code point.
>
> Ok, I've just installed this change.

Thank you.  I've updated the Lisp manual.