From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: taylanbayirli@gmail.com (Taylan Ulrich =?utf-8?Q?Bay=C4=B1rl=C4=B1?= =?utf-8?Q?=2FKammer?=) Newsgroups: gmane.emacs.devel Subject: Re: Emacs rewrite in a maintainable language Date: Sat, 17 Oct 2015 18:25:21 +0200 Message-ID: <871tctxy1a.fsf@T420.taylan> 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> <87a8rhqzdd.fsf@fencepost.gnu.org> 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 1445099131 5085 80.91.229.3 (17 Oct 2015 16:25:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Oct 2015 16:25:31 +0000 (UTC) Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , Eli Zaretskii , emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 17 18:25:31 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 1ZnUIU-0002ap-1A for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 18:25:30 +0200 Original-Received: from localhost ([::1]:59021 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnUIT-0005GI-2I for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 12:25:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54388) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnUIP-0005G1-EU for emacs-devel@gnu.org; Sat, 17 Oct 2015 12:25:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZnUIO-0003zu-Ad for emacs-devel@gnu.org; Sat, 17 Oct 2015 12:25:25 -0400 Original-Received: from mail-wi0-x22d.google.com ([2a00:1450:400c:c05::22d]:33953) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnUIO-0003zl-2I; Sat, 17 Oct 2015 12:25:24 -0400 Original-Received: by wicgb1 with SMTP id gb1so44822510wic.1; Sat, 17 Oct 2015 09:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; bh=YIeSPXTMrbjEvQEdiJ9uML6y3KalS1o2bOtP6r6E9E8=; b=cZw8hgCEaaeXhUCMi3Vtoyj3v5NGcNHjhb74Ia9XK53qLiyhWvPAm58WuxKR46ZBRR qh4U3nwBKZ89bhaX/NokJpXKYbcXbFdAaIazF3qLiJGyBgb9Qf+aJIcBQCzEs5+GfN8k xXznDdTbbW8SqLtO4KlSOKitmquheA/LGY3pHyoQ5z4q18Qh30E5ddVKgav/K/I+lDrC WaxBfYxtnjNWrcjrRMwDDcLp8CpRWmJq8REXUCTbME+/7TM2UbVB+lHUO2RWpyIiQzG4 bwC5Oel58MhXSxkCJAw9LWHL/Q7t+0Uu7oCqFDbN3lcUlT34FiATZMXGr0GZwfT8GKcE KlBQ== X-Received: by 10.180.188.206 with SMTP id gc14mr10703236wic.37.1445099123286; Sat, 17 Oct 2015 09:25:23 -0700 (PDT) Original-Received: from T420.taylan ([2a02:908:c32:4740:221:ccff:fe66:68f0]) by smtp.gmail.com with ESMTPSA id bh5sm29178940wjb.42.2015.10.17.09.25.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Oct 2015 09:25:22 -0700 (PDT) In-Reply-To: <87a8rhqzdd.fsf@fencepost.gnu.org> (David Kastrup's message of "Sat, 17 Oct 2015 17:38:22 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22d 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:191847 Archived-At: David Kastrup writes: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> Guile strings are fine, thank you. I=E2=80=99ve used a bunch of >> language/environments and honestly, I=E2=80=99m definitely not ashamed o= f what >> Guile provides, contrary to what David and you seem to imply. > > It's quite irrelevant whether somebody is proud or ashamed rightfully or > not of what is there. It does not fit the bill for Emacs and can't be > coaxed into fitting the bill without substantial changes. Its character > range is hard-limited at the end of Unicode. It has no representation > for non-utf8 code bytes. It has no additional character codes available > for those (let alone the "overlong" 2-byte sequences that Emacs employs > for representing raw bytes 128-255 transparently) It cannot faithfully > represent a string where only parts are proper utf-8 and the rest is to > be reproduced exactly even when doing string operations on the utf-8 > parts. Its input- and output encodings are not independent from the > locale. > > The underlying string handling libraries are not even _prepared_ to deal > with such requirements. Nor are they prepared for passing such strings > transparently through and working with them. In addition, Guile does > not actually have utf-8 strings but represents strings as either 8-bit > or 32-bit fixed-width entities. Which makes indexing efficient but > incurs conversions even if you are just working with utf-8 like Emacs > does. > > In spite of only working with either UCS-8 or UCS-32 in its strings, > many of the primitives of GUILE have a preference for utf-8: you cannot > even pass UCS-32 into GUILE or get it out easily in spite of it being > its internal format. > > But when GUILE is used as an extension language rather than as a sole > implementation language, you'll need to pass strings in and out of it > constantly. And the only format where strings will get passed without > conversion is Latin-1. But when telling GUILE that everything is > Latin-1, you have only a limited amount of reasonably working string > operations at your disposal and you won't get to see character codes > larger than 255. > > All this most definitely is nothing that could not be fixed. But doing > that is comparatively harder when all attempts to do so or to bring the > problems to attention are met with defiance. I haven't followed the whole discussion but I'd like to remind that GuileEmacs already runs currently, and from what I know none of the problems it faces are related to string handling. It just lets Elisp strings be a separate data type. I guess the discussion was about rewriting bigger parts of Emacs in Guile-Scheme, which might be one possible way to go forward but not necessary. Most of the benefits in e.g. http://www.emacswiki.org/emacs/GuileEmacs apply without having to solve the string problem. Specifically, from the overview section, the first two points and half of the third should apply I think. The third point only halfway because some Guile APIs might expect to receive Guile strings, so using them from Elisp code would be problematic, but Guile APIs which don't take strings should be fine. Anyway, the first two points are already pretty attractive, especially the second. Whatever language Emacs is written in, the native string library of the language will be insufficient, so meh. Taylan