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 17:05:00 +0200 Message-ID: <87bnq2o21v.fsf@fencepost.gnu.org> References: <54193A70.9020901@member.fsf.org> <87lhp6h4zb.fsf@panthera.terpri.org> <87k34qo4c1.fsf@fencepost.gnu.org> <54257C22.2000806@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1411744791 26562 80.91.229.3 (26 Sep 2014 15:19:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Sep 2014 15:19:51 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 26 17:19:46 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 1XXXJB-00052R-D8 for ged-emacs-devel@m.gmane.org; Fri, 26 Sep 2014 17:19:45 +0200 Original-Received: from localhost ([::1]:49787 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXXJA-0008R9-V7 for ged-emacs-devel@m.gmane.org; Fri, 26 Sep 2014 11:19:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33277) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXXIR-0007pA-74 for emacs-devel@gnu.org; Fri, 26 Sep 2014 11:19:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XXXIL-0006l1-RG for emacs-devel@gnu.org; Fri, 26 Sep 2014 11:18:59 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34238) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXXIL-0006hy-Lc for emacs-devel@gnu.org; Fri, 26 Sep 2014 11:18:53 -0400 Original-Received: from localhost ([127.0.0.1]:41063 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXX5D-0004kn-Fx; Fri, 26 Sep 2014 11:05:20 -0400 Original-Received: by lola (Postfix, from userid 1000) id 033B5E0EA9; Fri, 26 Sep 2014 17:05:01 +0200 (CEST) In-Reply-To: <54257C22.2000806@yandex.ru> (Dmitry Antipov's message of "Fri, 26 Sep 2014 18:45:54 +0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.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:174724 Archived-At: Dmitry Antipov writes: > On 09/26/2014 06:15 PM, David Kastrup wrote: > >> 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. > > Adopting Emacs? Why not just use ICU? This project's page claims about > "GPL-compatible" free license (http://userguide.icu-project.org/icufaq). Because ICU is not under the control of the GNU project. Whenever there is a need that needs to be fulfilled, it is not a priority for ICU. For example, it is an error for ICU if some string cannot properly be decoded. Emacs is capable of decoding random byte strings "as utf-8" and reencode them afterwards resulting in the original byte string, by using special characters to indicate "undecodable byte". This means that if you edit some source code file where comments have been added in different encodings, or which contains strings in several different encodings for whatever reason, you can save the file afterwards and have it only changed in those sections you actually edited, without any modifications in sections you did not touch but which still had to go through decoding on load and encoding on save. For an editor, those are very important features. For a third-party library, stuff like that may not be a priority. In addition, Emacs' string handling and encoding/reencoding has a longer history than UTF-8 and most such libraries. It's mature, and it definitely fits Emacs' bill. -- David Kastrup