From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.org!not-for-mail
From: David Kastrup <dak@gnu.org>
Newsgroups: gmane.emacs.devel
Subject: Re: Emacs Lisp's future
Date: Mon, 13 Oct 2014 12:30:29 +0200
Message-ID: <87siisxnwa.fsf@fencepost.gnu.org>
References: <87d2ahm3nw.fsf@fencepost.gnu.org>
	<E1XatgZ-00062a-AU@fencepost.gnu.org>
	<87zjd9swfj.fsf@uwakimon.sk.tsukuba.ac.jp>
	<E1XbfQa-0000UU-6N@fencepost.gnu.org>
	<87oatnqpml.fsf@uwakimon.sk.tsukuba.ac.jp>
	<E1Xc2OK-0001mE-Ct@fencepost.gnu.org>
	<874mvdrj45.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20141009044917.GA19957@fencepost.gnu.org> <83lhopisfr.fsf@gnu.org>
	<87ppe1pldu.fsf@uwakimon.sk.tsukuba.ac.jp>
	<8761ft5wpo.fsf@fencepost.gnu.org>
	<E1XcHRH-00079S-4b@fencepost.gnu.org> <83k349b0vj.fsf@gnu.org>
	<E1Xd9lm-0000Yz-69@fencepost.gnu.org> <83bnph96kh.fsf@gnu.org>
	<E1XdW1T-0007Ae-QA@fencepost.gnu.org>
	<87ppdwo7ll.fsf@uwakimon.sk.tsukuba.ac.jp> <83y4sk7biu.fsf@gnu.org>
	<87k344nzqw.fsf@uwakimon.sk.tsukuba.ac.jp>
	<8761foz6pi.fsf@fencepost.gnu.org>
	<87h9z8nw0q.fsf@uwakimon.sk.tsukuba.ac.jp>
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Trace: ger.gmane.org 1413196255 2515 80.91.229.3 (13 Oct 2014 10:30:55 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Mon, 13 Oct 2014 10:30:55 +0000 (UTC)
Cc: rms@gnu.org, mikegerwitz@gnu.org, mhw@netris.org, dmantipov@yandex.ru,
	emacs-devel@gnu.org, handa@gnu.org, monnier@iro.umontreal.ca,
	Eli Zaretskii <eliz@gnu.org>
To: "Stephen J. Turnbull" <stephen@xemacs.org>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 13 12:30:49 2014
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>
Envelope-to: ged-emacs-devel@m.gmane.org
Original-Received: from lists.gnu.org ([208.118.235.17])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	id 1Xdcto-00010C-32
	for ged-emacs-devel@m.gmane.org; Mon, 13 Oct 2014 12:30:44 +0200
Original-Received: from localhost ([::1]:32884 helo=lists.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	id 1Xdctn-00079m-M5
	for ged-emacs-devel@m.gmane.org; Mon, 13 Oct 2014 06:30:43 -0400
Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57669)
	by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <dak@gnu.org>)
	id 1Xdctk-00079U-B6
	for emacs-devel@gnu.org; Mon, 13 Oct 2014 06:30:41 -0400
Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <dak@gnu.org>) id 1Xdcti-0004BI-Jk
	for emacs-devel@gnu.org; Mon, 13 Oct 2014 06:30:40 -0400
Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59874)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <dak@gnu.org>)
	id 1Xdcti-0004BC-B2
	for emacs-devel@gnu.org; Mon, 13 Oct 2014 06:30:38 -0400
Original-Received: from localhost ([127.0.0.1]:38815 helo=lola)
	by fencepost.gnu.org with esmtp (Exim 4.71)
	(envelope-from <dak@gnu.org>)
	id 1Xdcta-0003ZZ-Cj; Mon, 13 Oct 2014 06:30:30 -0400
Original-Received: by lola (Postfix, from userid 1000)
	id E733CE069D; Mon, 13 Oct 2014 12:30:29 +0200 (CEST)
In-Reply-To: <87h9z8nw0q.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's
	message of "Mon, 13 Oct 2014 18:45:09 +0900")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
	(bad octet value).
X-Received-From: 2001:4830:134:3::e
X-BeenThere: emacs-devel@gnu.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: "Emacs development discussions." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-devel>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=subscribe>
Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org
Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org
Xref: news.gmane.org gmane.emacs.devel:175324
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/175324>

"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'".
>  >=20
>  > 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=A0remember.  Though I am pretty sure not to the degree of contributing
actual code.

>  > MULE (which is now pretty unavoidable in XEmacs as well I=A0_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.

--=20
David Kastrup