Re: Emacs Lisp's future

[Stephen J. Turnbull]

David Kastrup writes:

 > The alternative would be to create an encoding
 > utf-8-with-bad-linebreaks and the respective coders/recoders and
 > have that as the terminal encoding for running TeX.

Actually, Emacs *could* design a sane API where the error handler is
specified separate from the encoding.  This is *much* more important
here than it was with the EOL convention.

 > > Nevertheless, things are much better today than in the days when
 > > Erik Naggum declared that "Emacs has a fatal disease, and its
 > > name is 'MULE'".
 > 
 > Erik was the highest profile programmer/user abandoning Emacs for
 > XEmacs in order to avoid the consequences of multibyte encodings.

If he did, I never heard about it.  ISTR he hated XEmacs worse than he
hated Mule.  I know he stopped following the Emacs mainline, but AFAIK
he either went to a Common Lisp implementation like Hemlock, or rolled
his own based on a pre- Mule version of GNU Emacs, not XEmacs.

 > MULE (which is now pretty unavoidable in XEmacs as well I _think_)

No, XEmacs built fine without Mule as of early summer.  XEmacs 21.5 at
least has limited ability to deal with Unicode without Mule, but I
don't remember exactly how far it goes.  It may be that you're stuck
with Latin 1 characters as the internal repertoire, or it may be able
to deal with Unicode UTFs as long as the stream is limited to a
repertoire contained in a single unibyte character set.  If the
latter, you have to select fonts appropriately since such an XEmacs
knows nothing about non-Unicode character sets other than ASCII.

Of course if you want to deal sensibly with non-ASCII, you need to
build XEmacs with Mule, but there are a lot of American programmers
who don't need that even today.