emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs Lisp's future


From: David Kastrup
Subject: Re: Emacs Lisp's future
Date: Fri, 26 Sep 2014 17:05:00 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

Dmitry Antipov <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]