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 10:59:25 +0200 Message-ID: <87y4t5mob6.fsf@fencepost.gnu.org> References: <54193A70.9020901@member.fsf.org> <87lhp6h4zb.fsf@panthera.terpri.org> <87k34qo4c1.fsf@fencepost.gnu.org> <54257C22.2000806@yandex.ru> <87bnq2o21v.fsf@fencepost.gnu.org> <87vbo9wiz9.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 1411817450 31742 80.91.229.3 (27 Sep 2014 11:30:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 27 Sep 2014 11:30:50 +0000 (UTC) Cc: Dmitry Antipov , 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:30:41 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 1XXqCv-0005nw-V7 for ged-emacs-devel@m.gmane.org; Sat, 27 Sep 2014 13:30:34 +0200 Original-Received: from localhost ([::1]:55356 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXqCv-0004kR-IR for ged-emacs-devel@m.gmane.org; Sat, 27 Sep 2014 07:30:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47856) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXqCZ-0004hV-N9 for emacs-devel@gnu.org; Sat, 27 Sep 2014 07:30:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XXqCS-0000G2-RZ for emacs-devel@gnu.org; Sat, 27 Sep 2014 07:30:11 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37344) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXqCS-00005Z-Ns for emacs-devel@gnu.org; Sat, 27 Sep 2014 07:30:04 -0400 Original-Received: from localhost ([127.0.0.1]:44516 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXqCM-0007zJ-NL; Sat, 27 Sep 2014 07:29:59 -0400 Original-Received: by lola (Postfix, from userid 1000) id A3934E05D7; Sat, 27 Sep 2014 10:59:25 +0200 (CEST) In-Reply-To: <87vbo9wiz9.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Sat, 27 Sep 2014 17:44:26 +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:174737 Archived-At: "Stephen J. Turnbull" writes: > David Kastrup writes: > > Dmitry Antipov writes: > > > > Adopting Emacs? Why not just use ICU? This project's page claims about > > > "GPL-compatible" free license (http://userguide.icu-project.org/icufaq). > > > > Because ICU is not under the control of the GNU project. > > You can say the same about the Linux kernel, for example. The last time I looked, Emacs ran on more platforms than GNU/Linux. We don't have a tie-in here. > Nevertheless, the HURD has never made it to ready-for-prime-time > status. At some point it's worth delegating maintenance of 99% of > your needs to another project, and Emacs has already been through the > Mule-to-Unicode internal encoding conversion. Would you really wish > that on another project? The point is that "GUILE" and "Emacs" are slated to be linked, and that will not happen if that would seriously degrade Emacs' usability for working with texts. It is a core capability of Emacs we are talking about here. > > In addition, Emacs' string handling and encoding/reencoding has a > > longer history than UTF-8 and most such libraries. It's mature, > > and it definitely fits Emacs' bill. > > I really doubt it will take much effort to move Emacs to ICU (compared > to grafting Emacs's complex internal facilities onto another project). If it would not take much effort, then it should be attempted independently. Only in that manner can one properly estimate the respective performance, footprint, programming and compatibility impacts independently from those of moving to GUILE. But that still does not touch the problem of making a core tenet of Emacs, one where Emacs needs to perform better and more versatile than most other applications and where we are talking about much more performance-relevant behavior than for most applications, depend on an externally controlled and maintained library. That's a particularly important reason for evaluating an ICU dependency in a separate branch independent from GUILE first. -- David Kastrup