From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Sun, 12 Oct 2014 21:16:29 +0900 Message-ID: <871tqdpjoi.fsf@uwakimon.sk.tsukuba.ac.jp> References: <54193A70.9020901@member.fsf.org> <871tqneyvl.fsf@netris.org> <87d2a54t1m.fsf@yeeloong.lan> <83lhotme1e.fsf@gnu.org> <871tql17uw.fsf@yeeloong.lan> <838uktm9gw.fsf@gnu.org> <87h9zgarvp.fsf@fencepost.gnu.org> <83y4srjaot.fsf@gnu.org> <83r3yhiu8c.fsf@gnu.org> <83siiw9c6t.fsf@gnu.org> <83zjd3846e.fsf@gnu.org> <8738auyxke.fsf@netris.org> <874mvaoys7.fsf@uwakimon.sk.tsukuba.ac.jp> <87h9z91y52.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1413116241 8163 80.91.229.3 (12 Oct 2014 12:17:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 12 Oct 2014 12:17:21 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 12 14:17:14 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 1XdI5J-0005ok-Fz for ged-emacs-devel@m.gmane.org; Sun, 12 Oct 2014 14:17:13 +0200 Original-Received: from localhost ([::1]:57176 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdI5J-0006LE-39 for ged-emacs-devel@m.gmane.org; Sun, 12 Oct 2014 08:17:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53010) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdI50-0006L4-Ud for emacs-devel@gnu.org; Sun, 12 Oct 2014 08:17:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XdI4t-0005ce-Dz for emacs-devel@gnu.org; Sun, 12 Oct 2014 08:16:54 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:54848) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdI4l-0005ai-C6; Sun, 12 Oct 2014 08:16:39 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 1BDCB1C39B0; Sun, 12 Oct 2014 21:16:30 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 0DDA11A2888; Sun, 12 Oct 2014 21:16:30 +0900 (JST) In-Reply-To: <87h9z91y52.fsf@fencepost.gnu.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 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:175287 Archived-At: David Kastrup writes: > Richard was _part_ of the Emacs 20 efforts and basically the one > who forced the MULE issue, and Stephen was on the XEmacs side which > now has ailed in popularity not least of all because Emacs tends to > work better in practice _now_ regarding the current prevalence of > multibyte codings in FWIW I don't recall it being a big deal, except for the noise you personally made about rawbytes support for AUCTeX (and correctly so, although we were unable to anything about it as quickly as we would have liked). > spite of XEmacs being earlier in aligning itself internally with > utf-8 (If memory serves me right). XEmacs introduced Mule earlier, and was the development platform for "UTF-2000" and later "Chise" XEmacs which did use UTF-8 internally, but according to Ben who was doing most of the work at that time, that code was unmaintainable and not adaptable for Windows so was not adopted in the mainline. XEmacs still uses Mule code internally. (It doesn't really matter except for convenience in the increasingly important case of Unicode being the external encoding, and potentially for access to externally developed software such as the UCD and ICU, or even PEP 393. The most important convenience is in design: Unicode has already dealt with most of the interesting issues in character sets.) > I can understand GUILE developers being unaware of the experience > we gained through all those years. But I am baffled at those who > _led_ the respective efforts wanting to repeat history, It's not a question of repeating history. History cannot be repeated, because Unicode has won. Mule is a niche feature, of rapidly decreasing importance. And history can't be repeated for another reason. Guile has no history of incorporating Mule features, or even Mule-enabling features. The question is whether Guile should adopt features designed in the 1990s for the 1990s environment (in *Japan*, the most snafued charset environment imaginable, I'll remind you) in order to better support Emacs, or whether Emacs should port existing support to Guile. The competition is severe, and there are many very strong alternatives for the use cases Guile would like to serve: Java, Python, Perl, and Ruby, and you can add PHP for web applications. Guile can't afford to acquire the kind of reputation that PHP had for carelessness in security matters.