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: Sun, 18 Oct 2015 17:31:33 +0200 Message-ID: <87si58mbvu.fsf@fencepost.gnu.org> References: <561A19AB.5060001@cumego.com> <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> <83si594wt3.fsf@gnu.org> <87io64iigs.fsf@gnu.org> <87r3kso1gr.fsf@fencepost.gnu.org> <87wpuks5ek.fsf@T420.taylan> <876124nwnt.fsf@fencepost.gnu.org> <87h9los0ic.fsf@T420.taylan> 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 1445182408 17049 80.91.229.3 (18 Oct 2015 15:33:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 18 Oct 2015 15:33:28 +0000 (UTC) Cc: Ludovic =?iso-8859-1?Q?Court=E8s?= , Eli Zaretskii , emacs-devel@gnu.org To: taylanbayirli@gmail.com (Taylan Ulrich =?utf-8?Q?=22Bay=C4=B1rl=C4=B1?= =?utf-8?Q?=2FKammer=22?=) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 18 17:33:24 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 1ZnpxY-0008Ip-Ej for ged-emacs-devel@m.gmane.org; Sun, 18 Oct 2015 17:33:20 +0200 Original-Received: from localhost ([::1]:34301 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnpxX-0002yP-9a for ged-emacs-devel@m.gmane.org; Sun, 18 Oct 2015 11:33:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49505) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnpxK-0002yI-4U for emacs-devel@gnu.org; Sun, 18 Oct 2015 11:33:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZnpxI-0002nr-NO for emacs-devel@gnu.org; Sun, 18 Oct 2015 11:33:06 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48220) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnpxE-0002nP-AC; Sun, 18 Oct 2015 11:33:00 -0400 Original-Received: from localhost ([127.0.0.1]:33806 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1ZnpxD-0004go-5o; Sun, 18 Oct 2015 11:32:59 -0400 Original-Received: by lola (Postfix, from userid 1000) id 0E08BDF535; Sun, 18 Oct 2015 17:31:33 +0200 (CEST) In-Reply-To: <87h9los0ic.fsf@T420.taylan> ("Taylan Ulrich =?utf-8?Q?=5C=22Bay=C4=B1rl=C4=B1=2FKammer=5C=22=22's?= message of "Sun, 18 Oct 2015 16:40:43 +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:191957 Archived-At: taylanbayirli@gmail.com (Taylan Ulrich "Bay=C4=B1rl=C4=B1/Kammer") writes: > David Kastrup writes: > >> taylanbayirli@gmail.com (Taylan Ulrich "Bay=C4=B1rl=C4=B1/Kammer") write= s: >> >>> David Kastrup writes: >> >> It is not the job of an extension language to dictate application >> behavior. > > It is the job of programming tools to aid programmers in writing good > applications. As long as you call Emacs a bad application because of its support of a large number of encodings and situations beyond Unicode and utf-8, support that was driven by user requirements and has been a long series of improvements, you are not on a good road to sell GuileEmacs to either Emacs or GUILE developers. >> It is not the job of an extension language to dictate the concept of >> "character". Of course, not everything can be supported out of the >> box and there are limits to what can be supported due to technical >> reasons. However, the stance of the GUILE developers is to stop >> people using GUILE from doing things they consider not their problem. > > What is a character and what is a string is understood very well, and > Guile provides clean abstractions for these, as any sane general > purpose language should. GUILE does not provide an "abstraction" but rather is Unicode-only to a degree where (integer->char #xD800) produces an error, making it even impossible to manipulate CESU-8 strings. > While I can't speak for the Guile developers, I can assure you that > their stance is to provide the best possible abstractions a general > purpose language should provide. Again: if GUILE is no longer considered an extension language, this needs to be communicated to GNU in order to adapt its intended and advertised role in the GNU project. >> This stance, possibly partly due to only a single developer working >> in isolation on the "unstable" branch and everybody else confined to >> changes in the "stable" branch, is going to end a roadblock for >> projects like GuileEmacs. > > You seem to be making wrong assumptions about Guile's development > model. I don't think the fact that the upcoming 2.2 has been mostly a > one person project has much to do with the incompatibilities between > 1.x and 2.x. That's not what I said. What I said is that work on the encoding problems of GUILE (and having to do conversions for passing a GUILE-internal string through a GUILE-internal string port is a problem) has no place since the "unstable branch" contains just single-person compiler-focused work while such changes in a "stable branch" would be uncalled for. This setup leads to a strong defensive stance preferring the status quo since there is no place for most changes that are not mere bugfixes or incremental improvements to go to. >>> For arbitrary byte vectors, Guile has bytevectors (surprise!!). >>> >>> If one implemented a text editor from scratch in Guile and wanted to >>> allow editing files with no proper encoding, one would use an >>> abstraction on top of bytevectors. >> >> It is not the job of an extension language to dictate what >> constitutes "proper encoding". It is the job of the application. > > Yes, it *is* the job of a string library to offer abstractions for > well-defined encodings of strings. Shrug. "abstraction" is not the same as "restriction". Unicode is not an abstraction. It's a reference point for an implementation. And as a reference it was good and versatile enough that Emacs changed its multibyte implementation in Emacs 23 to one based on UTF-8 and Unicode internally. And because Emacs multibyte encodings were rather well-abstracted at the application layer, this change, while extensive and pervasive, was surprisingly non-disruptive for applications. >> GUILE is first and foremost an extension language. That is how it >> advertises itself on its web page. That it supports the >> general-purpose programming language Scheme is a boon and >> implementation choice. >> >> If GUILE developers insist on GUILE being foremost a general-purpose >> programming language rather than an extension language, they should >> notify the GNU project and change their web page. There is no point >> in GNU promoting GUILE as an extension language if the GUILE >> developers are no longer on board with that target. > > You seem to be making a strange distinction between a general-purpose > and an extension language and implying that an "extension language" > should fill exactly the use-cases of Emacs for some reason... Not just Emacs. Pretty much every application that requires more specific error handling than rejecting an entire file or communication. Like, say, LilyPond. >> That is a pretty alien concept to established Emacs developers, Emacs >> being the proverbial glue and shoe string across dozens of different >> platforms right from the beginning of GNU where POSIX would have been >> luxury. > > Maybe some established Emacs developers should get with the times > then. Shrug. Files won't magically convert themselves into only containing material encodable by proper UTF-8 and nothing else. Dropping everything achieved in character and string handling since Emacs=C2=A020 so that GUILE must not adapt is not an option that is realistic. > I'm not interested in continuing this discussion because it's just as > unproductive as the last time. GuileEmacs has come *very* far, and > most arguments I hear against it seem based in apocalyptic FUD, and in > particular spitefulness due to past negative experiences with the > Guile 1.x/2.x transition, which has really nothing to do with > GuileEmacs, a Guile 2.x project. That is not to say it's going to be > fairies and pixies. There's significant work to be done on it and I > hope I will find some time to contribute to it in the not too distant > future. You'll not be able to restrict all changes to Emacs (GuileEmacs being a branch of Emacs development). There are changes and improvements necessary in GUILE itself to make it viable as a platform for running Emacs on. Denying that is doing a disfavor to those who have invested considerable work into GuileEmacs by now since it makes it less than more likely that GuileEmacs can sensibly become the main implementation of Emacs. --=20 David Kastrup