Ar an seachtú lá déag de mí Aibréan, scríobh Stephen J. Turnbull>: Java does it that way; the idea was to make it comfortable for people coming from there. That said, allowing variable-length constants and only allowing the escapes in characters and strings already makes it unfamiliar to Java people. I think triggering an error for that should be done in Funicode_to_char, not in the Lisp reader. That way it would be available to all the Unicode-oriented coding systems. You see a one-digit octal constant in C all the time; '\0'. You don’t see two-digit octal constants because people are used to C where two-digit octal constants (including the leading zero) are identical to their decimal counterparts, except that they’re more typing. That is, 07 means exactly the same as 7, 03 means exactly the same as 3. (I much prefer hex escapes to octal escapes, myself, and drop leading zeroes there all the time.) Well, not for line feed, I would imagine, people will stick with the old syntax. For punctuation and Han characters, they’re four digits already; the variable length only becomes useful for people using non-Roman alphabets, like Greek, Cyrillic, Hebrew and Arabic. If anyone reading this uses any of them, shout! That patch handles strings already--the Lisp reader handles strings as a succession of characters, but without question marks. I suspect that also programmers not paying full attention (so, all of us, at one point or another) would write things like "1\U239645" where they didn’t mean the 45 to be part of the Unicode symbol. I think that the earlier we introduce it, the better. Look how long it’s taken for people to adapt #x in Lisp code, and that was a function of the date of introduction of the syntax first in XEmacs and then in GNU Emacs. -- In the beginning God created the heavens and the earth. And God was a bug-eyed, hexagonal smurf with a head of electrified hair; and God said: “Si, mi chiamano Mimi...”

NOTE: This patch has been committed. SUPERSEDES 17474.44623.340909.789205(a)parhasard.net Ar an fichiú lá de mí Aibréan, scríobh Stephen J. Turnbull: Okay, fixed width it is. They don’t have it currently, and they have the same problem with their internal representation, and so would have the same benefit from it. I’ve sent an implementation their way. I suspect if not ignored because of the eternal release, it’ll be ignored because of its provenance. Oh well. ? A coding cookie’s not good enough? man/ChangeLog addition: 2006-04-29 Aidan Kehoe <kehoea(a)parhasard.net&gt; * lispref/objects.texi (Character Type): Document the Unicode syntax for characters in characters and strings. src/ChangeLog addition: 2006-04-29 Aidan Kehoe <kehoea(a)parhasard.net&gt; * lread.c: * lread.c (read_escape): Support \uABCD and \U00ABCDEF for specifying characters by their Unicode code point. XEmacs Trunk source patch: Diff command: cvs -q diff -u Files affected: src/lread.c man/lispref/objects.texi Index: man/lispref/objects.texi =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/man/lispref/objects.texi,v retrieving revision 1.7 diff -u -u -r1.7 objects.texi --- man/lispref/objects.texi 2003/06/30 09:31:01 1.7 +++ man/lispref/objects.texi 2006/04/29 14:32:22 ＠＠ -510,6 +510,21 ＠＠ For example, character code 193 is a lowercase ＠samp{a} with an acute accent, in ＠sc{iso}-8859-1.) +＠cindex unicode character escape + From version 21.5.25 onwards, XEmacs provides a syntax for specifying +characters by their Unicode code points. ＠samp{?\uABCD} will give you +an XEmacs character that maps to the code point ＠samp{U+ABCD} in +Unicode-based representations (UTF-8 text files, Unicode-oriented fonts, +etc.) Just as in the C# language, there is a slightly different syntax +for specifying characters with code points above ＠samp{#xFFFF}; +＠samp{\U00ABCDEF} will give you an XEmacs character that maps to the +code point ＠samp{U+ABCDEF} in Unicode-based representations, if such an +XEmacs character exists. + + Unlike in C#, while this syntax is available for character literals, +and (see later) in strings, it is not available elsewhere in your Lisp +source code. + ＠ignore ＠c None of this crap applies to XEmacs. For use in strings and buffers, you are limited to the control characters that exist in ＠sc{ascii}, but for keyboard input purposes, ＠＠ -614,6 +629,7 ＠＠ ＠cindex backslash in character constant ＠cindex octal character code ＠cindex hexadecimal character code + Finally, there are two read syntaxes involving character codes. It is not possible to represent multibyte or wide characters in this way; the permissible range of codes is from 0 to 255 (＠emph{i.e.}, Index: src/lread.c =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/src/lread.c,v retrieving revision 1.76 diff -u -u -r1.76 lread.c --- src/lread.c 2005/07/12 23:26:49 1.76 +++ src/lread.c 2006/04/29 14:32:23 ＠＠ -208,6 +208,8 ＠＠ static int locate_file_open_or_access_file (Ibyte *fn, int access_mode); EXFUN (Fread_from_string, 3); +EXFUN (Funicode_to_char, 2); /* In unicode.c. */ + /* When errors are signaled, the actual readcharfun should not be used as an argument if it is an lstream, so that lstreams don't escape to the Lisp level. */ ＠＠ -1675,6 +1677,9 ＠＠ { /* This function can GC */ Ichar c = readchar (readcharfun); + /* \u allows up to four hex digits, \U up to eight. Default to the + behaviour for \u, and change this value in the case that \U is seen. */ + int unicode_hex_count = 4; if (c < 0) signal_error (Qend_of_file, 0, READCHARFUN_MAYBE (readcharfun)); ＠＠ -1763,7 +1768,7 ＠＠ } } if (i >= 0400) - syntax_error ("Attempt to create non-ASCII/ISO-8859-1 character", + syntax_error ("Non-ISO-8859-1 character specified with octal escape", make_int (i)); return i; } ＠＠ -1791,11 +1796,51 ＠＠ } return i; } + case 'U': + /* Post-Unicode-2.0: Up to eight hex chars */ + unicode_hex_count = 8; + case 'u': + /* A Unicode escape, as in C# (though we only permit them in strings + and characters, not arbitrarily in the source code.) */ + { + REGISTER Ichar i = 0; + REGISTER int count = 0; + Lisp_Object lisp_char; + while (++count <= unicode_hex_count) + { + c = readchar (readcharfun); + /* Remember, can't use isdigit(), isalpha() etc. on Ichars */ + if (c >= '0' && c <= '9') i = (i << 4) + (c - '0'); + else if (c >= 'a' && c <= 'f') i = (i << 4) + (c - 'a') + 10; + else if (c >= 'A' && c <= 'F') i = (i << 4) + (c - 'A') + 10; + else + { + syntax_error ("Non-hex digit used for Unicode escape", + make_char (c)); + break; + } + } + + lisp_char = Funicode_to_char(make_int(i), Qnil); + + if (EQ(Qnil, lisp_char)) + { + /* This is ugly and horrible and trashes the user's data, but + it's what unicode.c does. In the future, unicode-to-char + should not return nil. */ #ifdef MULE - /* #### need some way of reading an extended character with - an escape sequence. */ + i = make_ichar (Vcharset_japanese_jisx0208, 34 + 128, 46 + 128); +#else + i = '~'; #endif + return i; + } + else + { + return XCHAR(lisp_char); + } + } default: return c; cvs server: src/xft-fonts.h is a new entry, no comparison available -- In the beginning God created the heavens and the earth. And God was a bug-eyed, hexagonal smurf with a head of electrified hair; and God said: “Si, mi chiamano Mimi...”

Ar an triochadú lá de mí Aibréan, scríobh Stephen J. Turnbull: I’ve already assigned my Emacs code to them, and am prepared to do the work. I’ll be interested to see how they react. In what way? -- In the beginning God created the heavens and the earth. And God was a bug-eyed, hexagonal smurf with a head of electrified hair; and God said: “Si, mi chiamano Mimi...”

Aidan Kehoe <kehoea(a)parhasard.net&gt; wrote: What version of Java has the \U escapes? The language specification says that only lower-case 'u' is a Unicode escape: http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.3 and that representing supplementary characters requires two consecutive \u escapes (because Java means "UTF-16" when it says "Unicode"). Indeed, try this experiment with Sun's JDK 1.5.0_06. This code compiles and prints what is expected when run: public class Test { public static void main(String[] args) { System.out.println("This is a zero: " + '\u0030'); } } but this one produces compiler errors: public class Test { public static void main(String[] args) { System.out.println("This is a zero: " + '\U00000030'); } } $ javac Test.java Test.java:3: illegal escape character System.out.println("This is a zero: " + '\U00000030'); ^ Test.java:3: unclosed character literal System.out.println("This is a zero: " + '\U00000030'); ^ Test.java:3: unclosed character literal System.out.println("This is a zero: " + '\U00000030'); ^ Test.java:3: ')' expected System.out.println("This is a zero: " + '\U00000030'); ^ 4 errors (Not that I'm saying it's a bad idea for us to do it that way. I'm just questioning the claim that Java does it that way.) Regards, -- Jerry James, Assistant Professor james(a)xemacs.org Computer Science Department http://www.cs.usu.edu/~jerry/ Utah State University