Re: Emacs Lisp's future

[Stephen J. Turnbull]

David Kastrup writes:

 > Richard was _part_ of the Emacs 20 efforts and basically the one
 > who forced the MULE issue, and Stephen was on the XEmacs side which
 > now has ailed in popularity not least of all because Emacs tends to
 > work better in practice _now_ regarding the current prevalence of
 > multibyte codings in

FWIW I don't recall it being a big deal, except for the noise you
personally made about rawbytes support for AUCTeX (and correctly so,
although we were unable to anything about it as quickly as we would
have liked).

 > spite of XEmacs being earlier in aligning itself internally with
 > utf-8 (If memory serves me right).

XEmacs introduced Mule earlier, and was the development platform for
"UTF-2000" and later "Chise" XEmacs which did use UTF-8 internally,
but according to Ben who was doing most of the work at that time, that
code was unmaintainable and not adaptable for Windows so was not
adopted in the mainline.  XEmacs still uses Mule code internally.  (It
doesn't really matter except for convenience in the increasingly
important case of Unicode being the external encoding, and potentially
for access to externally developed software such as the UCD and ICU,
or even PEP 393.  The most important convenience is in design: Unicode
has already dealt with most of the interesting issues in character
sets.)

 > I can understand GUILE developers being unaware of the experience
 > we gained through all those years.  But I am baffled at those who
 > _led_ the respective efforts wanting to repeat history,

It's not a question of repeating history.  History cannot be repeated,
because Unicode has won.  Mule is a niche feature, of rapidly
decreasing importance.

And history can't be repeated for another reason.  Guile has no
history of incorporating Mule features, or even Mule-enabling
features.  The question is whether Guile should adopt features
designed in the 1990s for the 1990s environment (in *Japan*, the most
snafued charset environment imaginable, I'll remind you) in order to
better support Emacs, or whether Emacs should port existing support to
Guile.

The competition is severe, and there are many very strong alternatives
for the use cases Guile would like to serve: Java, Python, Perl, and
Ruby, and you can add PHP for web applications.  Guile can't afford to
acquire the kind of reputation that PHP had for carelessness in
security matters.