Re: Emacs Lisp's future

[David Kastrup <dak@gnu.org>]

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

> 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.

At first glance, indeed I find
<URL:http://www.emacswiki.org/ErikNaggum#toc1>, the "multibyte survival
kit" for Emacs.

Here's some discussion involving Erik Naggum and myself in 1997 about
MULE and Emacs 20
<URL:https://groups.google.com/forum/#!topic/comp.emacs/ge7syiq7oy8>.
Interesting historic read.

Erik says in that thread "XEmacs has done this right: offer MULE as an
option at build-time.".  At any rate, it is funny to see that I propose
using an array-of-characters programming model with underlying multibyte
representation there, which is dismissed by Erik as not tenable.

Of course, it is what we _have_ since about Emacs 20.3 or 20.4 or so.

So at any rate: at a cursory search I find nothing supporting my
statement about Erik and XEmacs, but some references that may explain
the direction I misremember.

I also find that I've been more involved with coding sanity issues than
I remember.  Though I am pretty sure not to the degree of contributing
actual code.

>  > 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.

Ok, so that state is basically like the situation Erik lauded XEmacs
for.  My personal impression is that the historical
one-size-must-fit-all approach of Emacs has, after the initial pain it
caused, led to a situation and code base that does a reasonable job at
keeping the costs of versatility as well in check as can be expected.
We don't have the "you should have been using other compilation options"
argument to fall back on, so it better should.

-- 
David Kastrup