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: Fri, 26 Sep 2014 16:15:42 +0200 Organization: Organization?!? Message-ID: <87k34qo4c1.fsf@fencepost.gnu.org> References: <54193A70.9020901@member.fsf.org> <87lhp6h4zb.fsf@panthera.terpri.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1411740991 5989 80.91.229.3 (26 Sep 2014 14:16:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Sep 2014 14:16:31 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 26 16:16:26 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 1XXWJq-0008Cm-Id for ged-emacs-devel@m.gmane.org; Fri, 26 Sep 2014 16:16:22 +0200 Original-Received: from localhost ([::1]:49345 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXWJp-0004Jc-SK for ged-emacs-devel@m.gmane.org; Fri, 26 Sep 2014 10:16:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40845) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXWJe-0004AO-TA for emacs-devel@gnu.org; Fri, 26 Sep 2014 10:16:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XXWJV-00040t-D5 for emacs-devel@gnu.org; Fri, 26 Sep 2014 10:16:10 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:41967) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXWJV-00040K-7W for emacs-devel@gnu.org; Fri, 26 Sep 2014 10:16:01 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XXWJP-0007mz-1D for emacs-devel@gnu.org; Fri, 26 Sep 2014 16:15:55 +0200 Original-Received: from x2f43d90.dyn.telefonica.de ([2.244.61.144]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Sep 2014 16:15:55 +0200 Original-Received: from dak by x2f43d90.dyn.telefonica.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Sep 2014 16:15:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 64 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: x2f43d90.dyn.telefonica.de X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) Cancel-Lock: sha1:FJjq3TePAsu001kvW+335Oh+aQo= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:174721 Archived-At: Robin Templeton writes: > Kristian Nygaard Jensen writes: > >>> Of course, that's for the language side, but on the implementation side, >>> I don't really know what Common-Lisp implementation we could re-use >>> (both GNU implementations are dormant, so there's no manpower for us >>> tap into). Still: there are many Common-Lisp implementations out there, >>> so there's probably one that could work for us. >> >> Embeddable Common-Lisp (http://sourceforge.net/projects/ecls/) seems >> alive, it is lgpl, so there would be no license issue > > ECL's maintainer resigned last year: > . There have > been no releases since, and recent mailing list posts indicate that > there is no current maintainer. While not an example for how to keep one's temper, in the course of I suggest that Emacs buffers could be based on string ports with random access. The basic idea here is, of course, that the fundamental operation of a string port is adding unknown amounts of material "at point". Personally, I think that there is a lot of potential to tie strings, encodings, buffers, ports quite closely together in Emacs and Guile, and part of that reason is that I consider Emacs' multinational string/buffer/multibyte/unibyte handling a lot more mature in concepts and implementation than that of GUILE. Scheme does not prescribe a whole lot regarding the details of character sets and string handling (except that Scheme strings tend to have a stronger focus on being rewritable, something that works pretty badly on variable-length encodings but which Emacs purports to support at least using aset). And I think that the user and application pressure on Emacs/MULE in that regard has in the time since Emacs 20 lead to pretty good solutions. GUILE in particular has problems coming to grips about the difference between "internal UTF-8 based encoding" and "external UTF-8 encoding which might contain bytes violating the UTF-8 guarantees" and not having unnecessary crossbleed between them. Since Emacs historically had a completely different internal multibyte encoding, it has kept those apart much cleaner. If GUILE wants to take over Emacs regarding its computing, I think it first has to get itself infiltrated by Emacs' handling of strings and buffers. I have no idea whether this should go as far as to replace iconv with CCL programs. It would have the advantage of using actively maintained and used GNU-controlled technology for the multi-language stuff (and Emacs is rather good in that area), but I have no idea how good a fit this could be. At any rate: the Scheme standards leave a lot things open regarding actual multinational character set and string support, and I feel that the historic pressure of the text-based Emacs might have done a better job so far of producing concepts and results that work well in practice than what the GUILE developers were forced to work with regarding foreign alphabets. So instead of interfacing one to the other, I think GUILE has more to win than to lose by adopting some of the Emacs concepts and data models regarding text/string processing rather than designing its own. -- David Kastrup