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 rewrite in a maintainable language Date: Sat, 17 Oct 2015 17:38:22 +0200 Message-ID: <87a8rhqzdd.fsf@fencepost.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> 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 1445096721 1511 80.91.229.3 (17 Oct 2015 15:45:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Oct 2015 15:45:21 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 17 17:45:19 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 1ZnTfb-0001he-5R for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 17:45:19 +0200 Original-Received: from localhost ([::1]:58788 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnTfa-0002te-Gf for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 11:45:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44162) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnTel-00023j-Dm for emacs-devel@gnu.org; Sat, 17 Oct 2015 11:44:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZnTek-0007iL-Ef for emacs-devel@gnu.org; Sat, 17 Oct 2015 11:44:27 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56396) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnTei-0007gy-4t; Sat, 17 Oct 2015 11:44:24 -0400 Original-Received: from localhost ([127.0.0.1]:41975 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1ZnTee-0000Di-5H; Sat, 17 Oct 2015 11:44:20 -0400 Original-Received: by lola (Postfix, from userid 1000) id 796A7E14A3; Sat, 17 Oct 2015 17:38:22 +0200 (CEST) In-Reply-To: <87lhb1n81y.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?= =?iso-8859-1?Q?=22's?= message of "Sat, 17 Oct 2015 11:44:25 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.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:191841 Archived-At: 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 of= 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. --=20 David Kastrup