From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs rewrite in a maintainable language Date: Sat, 17 Oct 2015 13:24:40 +0300 Message-ID: <83si594wt3.fsf@gnu.org> References: <561A19AB.5060001@cumego.com> <87io6dl0h0.fsf@wanadoo.es> <87lhb82qxc.fsf@gmail.com> <87oag4jk74.fsf@wanadoo.es> <87k2qrki45.fsf@wanadoo.es> <8737xf9je9.fsf@fencepost.gnu.org> <87pp0fm0j3.fsf@gnu.org> <87r3kusx8z.fsf@fencepost.gnu.org> <83lhb26eb9.fsf@gnu.org> <876126key3.fsf@gnu.org> <83fv1a6bfu.fsf@gnu.org> <87d1weo7u9.fsf@gnu.org> <83zizi3qr0.fsf@gnu.org> <87lhb1n81y.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1445077508 21065 80.91.229.3 (17 Oct 2015 10:25:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Oct 2015 10:25:08 +0000 (UTC) Cc: emacs-devel@gnu.org To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 17 12:24:59 2015 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 1ZnOfa-0003MA-He for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 12:24:58 +0200 Original-Received: from localhost ([::1]:57724 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnOfZ-0008VY-Ox for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 06:24:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41131) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnOfM-0008VQ-H4 for emacs-devel@gnu.org; Sat, 17 Oct 2015 06:24:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZnOfG-0006hH-TQ for emacs-devel@gnu.org; Sat, 17 Oct 2015 06:24:42 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:57521) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnOfG-0006hB-Kk; Sat, 17 Oct 2015 06:24:38 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NWD00B000R5KA00@a-mtaout20.012.net.il>; Sat, 17 Oct 2015 13:24:37 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWD00BFO0X0KE00@a-mtaout20.012.net.il>; Sat, 17 Oct 2015 13:24:37 +0300 (IDT) In-reply-to: <87lhb1n81y.fsf@gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:191816 Archived-At: > From: ludo@gnu.org (Ludovic Court=C3=A8s) > Cc: emacs-devel@gnu.org > Date: Sat, 17 Oct 2015 11:44:25 +0200 >=20 > >> My point is: Emacs can keep doing its own thing in that area. > > > > Of course. But that takes away a serious chunk of arguments in f= avor > > of Guile-based Emacs, for 2 reasons: (a) there will have to be a > > non-trivial translation layer between the two, and (b) a very lar= ge > > part of Emacs's C core will have to be left intact, instead of > > removing it because Guile already does that. >=20 > AFAIK nobody claims that Guile is the right choice due to its i18n > support. >=20 > The main claims are: the compiler, VM (which would no longer be par= t of > Emacs), FFI, libraries, etc. >=20 > That chunk isn=E2=80=99t taken away. I agree. But those features are additions to what Emacs already has. They are advantages for the future. This thread talks about a "rewrite", i.e. about replacing the existing C code with something that will be more maintainable and will attract new developers easier than the current C core. With that perspective, advantages for the future are less relevant; what is more relevant is how much of the current C core could be replaced by Guile, and how much will have to be rewritten in Guile Scheme or left in C. > Guile strings are fine, thank you. I=E2=80=99ve used a bunch of > language/environments and honestly, I=E2=80=99m definitely not asha= med of what > Guile provides, contrary to what David and you seem to imply. I didn't mean to imply that Guile development should be ashamed. But please consider this: the first version of Emacs i18n was released with Emacs 20.1. People who designed and implemented it were not stupid, and the result was nothing to be ashamed of, either: it solve= d a very large part of the problem it was intended to solve. And yet since then the v20.1 implementation on various levels was significantly changed no less than 2 times, in response to real-life experience and user feedback. If we speak today about some non-trivial conclusions drawn from that, we are speaking armed with that experience. Guile's i18n is today where Emacs was at v20.1, with the (important) difference that its internal representation is based on Unicode and UTF-8. The lessons of Emacs development since then till today are ye= t to be learned and incorporated into Guile. I really think Guile developers should seriously study the Emacs experience, if Guile is supposed to support multi-lingual environments. For example, IMO Guile relies too much on the underlying libc, in particular on the locale-dependent services libc provides. A multi-lingual text-processing environment such as Emacs cannot depend on locales, because each locale supports only one language. Emacs includes support for multiple languages in the same buffer/file that simply cannot be easily implemented using locale-dependent features. By contrast, Guile is quite good in supporting a single language, but not as good when several different languages/scripts are to be mixed in the same string. E.g., consider a simple problem of counting characters in such a string -- the libc functions like mbslen are not guaranteed to support this outside of the current language/locale.