Re: Emacs Lisp's future

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > Date: Fri, 26 Sep 2014 18:45:54 +0400
 > > From: Dmitry Antipov <address@hidden>
 > > Cc: address@hidden
 > > 
 > > Why not just use ICU?
 > 
 > Emacs needs to be able to extend the Unicode code-point space for raw
 > 8-bit bytes and for a couple of character sets that are not unified.

No, you don't.  There's plenty of private space for those purposes
(unless you know of private character sets that use more than two
whole planes?)  Emacs would simply use an indirect representation for
private space.  (That is, code points in private space are not
necessarily identical to the input code points, but rather are indexes
into an auxiliary table which implements the disjoint sum of the
private code spaces in use.)

Since this is private space, you need to build a table of attributes
for these characters (I/O representation, UCD properties, glyphs, etc)
anyway.  For Unicode input using private space, you just record that
as the I/O representation.

 > Can ICU support that?

Maybe it would be unhappy if you used a lone surrogate representation
(or other representation using integers outside of the Unicode
character space) for those "extended code points", but as proposed
above you can efficiently use private space in practice.