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: Sat, 27 Sep 2014 13:13:26 +0200 Message-ID: <87tx3tmi3t.fsf@fencepost.gnu.org> References: <54193A70.9020901@member.fsf.org> <87lhp6h4zb.fsf@panthera.terpri.org> <87k34qo4c1.fsf@fencepost.gnu.org> <54257C22.2000806@yandex.ru> <83iokato6x.fsf@gnu.org> <87wq8pwjen.fsf@uwakimon.sk.tsukuba.ac.jp> <837g0ptnlj.fsf@gnu.org> <87r3yxwdr6.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1411817474 32015 80.91.229.3 (27 Sep 2014 11:31:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 27 Sep 2014 11:31:14 +0000 (UTC) Cc: Kenichi Handa , Eli Zaretskii , dmantipov@yandex.ru, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 27 13:31:06 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 1XXqDO-0006BW-HP for ged-emacs-devel@m.gmane.org; Sat, 27 Sep 2014 13:31:02 +0200 Original-Received: from localhost ([::1]:55359 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXqDO-0005PG-5S for ged-emacs-devel@m.gmane.org; Sat, 27 Sep 2014 07:31:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47845) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXqCX-0004db-1I for emacs-devel@gnu.org; Sat, 27 Sep 2014 07:30:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XXqCW-0000Ku-6A for emacs-devel@gnu.org; Sat, 27 Sep 2014 07:30:08 -0400 Original-Received: from fencepost.gnu.org ([208.118.235.10]:38903) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXqCW-0000Ep-41 for emacs-devel@gnu.org; Sat, 27 Sep 2014 07:30:08 -0400 Original-Received: from localhost ([127.0.0.1]:44518 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXqCM-0007zL-NQ; Sat, 27 Sep 2014 07:29:58 -0400 Original-Received: by lola (Postfix, from userid 1000) id 7D3F2E08F5; Sat, 27 Sep 2014 13:13:26 +0200 (CEST) In-Reply-To: <87r3yxwdr6.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Sat, 27 Sep 2014 19:37:17 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.10 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:174738 Archived-At: "Stephen J. Turnbull" writes: > Eli Zaretskii writes: > > > I take it that you have studied the charsets for which we use > > codepoints above 0x10FFFF, and concluded that they all fit in the > > 2*64K+6.4K PUA space provided by Unicode? > > No, I've studied the coded character sets that are actually used by > real people in this world, and concluded that for practical purposes, For practical purposes, real people use Microsoft Word. > the Unicode coded character set plus the PUA permits representing all > of them satisfactorily for a TTY, and that the additional burden of > disambiguating them (eg, for font choice in a GUI) should be handled > by markup (eg, the XML lang attribute in text/* representations, and > text properties in Emacs). Emacs has invested a lot of work and energy into getting encodings right. MULE was the principal reason for the last large migration of Emacs users to XEmacs (around Emacs 20), and it was a significant reason for a slow but steady migration trickle back when multinational character sets became ubiquitous and the initial painful investment of Emacs into them paid back in the form of a longer matured implementation. I remember XEmacs having an implementation of the "works for real people for practical purposes" kind where the principal maintainers do not appear to be fundamentally immersed in the problem space. Because those for which multinational character sets were an essential feature went to work on and with Emacs instead. Whether or not that's revisionism, I think that there is little doubt that Emacs has a solid history of experience dealing with Far Eastern character sets and texts. The same cannot be said for R->L typesetting. However, the problems specific to R->L typesetting are mostly not in the character set and string handling area but rather concern the display algorithms where we already found that supporting all the functionality of Emacs is not well-supported by industry-standard solutions like Pango. In short, it is not likely we are talking about a no-brainer regarding rebasing MULE on something else. If we were, it would appear to me that XEmacs would have had more to gain from such a step than Emacs, and there is likely some reason that they chose not to do so. -- David Kastrup