Re: Emacs Lisp's future

[David Kastrup <dak@gnu.org>]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Eli Zaretskii writes:
>
>  > I take it that you have studied the charsets for which we use
>  > codepoints above 0x10FFFF, and concluded that they all fit in the
>  > 2*64K+6.4K PUA space provided by Unicode?
>
> No, I've studied the coded character sets that are actually used by
> real people in this world, and concluded that for practical purposes,

For practical purposes, real people use Microsoft Word.

> the Unicode coded character set plus the PUA permits representing all
> of them satisfactorily for a TTY, and that the additional burden of
> disambiguating them (eg, for font choice in a GUI) should be handled
> by markup (eg, the XML lang attribute in text/* representations, and
> text properties in Emacs).

Emacs has invested a lot of work and energy into getting encodings
right.  MULE was the principal reason for the last large migration of
Emacs users to XEmacs (around Emacs 20), and it was a significant reason
for a slow but steady migration trickle back when multinational
character sets became ubiquitous and the initial painful investment of
Emacs into them paid back in the form of a longer matured
implementation.  I remember XEmacs having an implementation of the
"works for real people for practical purposes" kind where the principal
maintainers do not appear to be fundamentally immersed in the problem
space.  Because those for which multinational character sets were an
essential feature went to work on and with Emacs instead.

Whether or not that's revisionism, I think that there is little doubt
that Emacs has a solid history of experience dealing with Far Eastern
character sets and texts.  The same cannot be said for R->L typesetting.
However, the problems specific to R->L typesetting are mostly not in the
character set and string handling area but rather concern the display
algorithms where we already found that supporting all the functionality
of Emacs is not well-supported by industry-standard solutions like
Pango.

In short, it is not likely we are talking about a no-brainer regarding
rebasing MULE on something else.  If we were, it would appear to me that
XEmacs would have had more to gain from such a step than Emacs, and
there is likely some reason that they chose not to do so.

-- 
David Kastrup