"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "Simon" == Simon Josefsson
<jas(a)extundo.com> writes:
Simon> non-problem and will even be fixed once the elisp parser in
Simon> Emacs understands ?#xCAFE. Thanks.
Er, XEmacs doesn't understand that either. XEmacs understands ?\x00
for a 1-byte character, and #xCAFE for an integer (in fact, up to
#7FFFFFFF).
Oops! I meant #xCAFE. The patch used it, and seems to work, so all
is well.
>> What about
http://www.unicode.org/Public/UNIDATA/? It
_will_
>> make sense to resurrect this notation in the near future, for
>> precisely that purpose. However, the reader will signal on
>> code points that are not assigned characters.
Simon> IMHO this should use a different syntax. Maybe ?\U4711 or
Simon> something.
Why? When it happens, Unicode will be the native character
representation for XEmacs.
Exposing the internal character representation doesn't seem like a
good idea to me, no matter what the internal representation is.
?U4711 makes it clear that it is Unicode and not the internal
representation. I think it would be useful to support ?4711 too, to
mean the 4711th native character, for performance reason or low-level
hackery, but when XEmacs switches to Genicode2100 (or whatever) elisp
code that use ?U4711 could still work.
Of course this is a very minor theoretical issue, and I'm not even
convinced it is the best solution engineering-wise; it may be too
convoluted.