[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs Lisp's future

From: Stephen J. Turnbull
Subject: Re: Emacs Lisp's future
Date: Mon, 13 Oct 2014 18:45:09 +0900

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]