From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup 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> <87zjd9swfj.fsf@uwakimon.sk.tsukuba.ac.jp> <87oatnqpml.fsf@uwakimon.sk.tsukuba.ac.jp> <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> <83k349b0vj.fsf@gnu.org> <83bnph96kh.fsf@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 To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 13 12:30:49 2014 Return-path: 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 ) 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 ) 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 ) 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 ) 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 ) 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 ) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: "Stephen J. Turnbull" 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 , the "multibyte survival kit" for Emacs. Here's some discussion involving Erik Naggum and myself in 1997 about MULE and Emacs 20 . 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