[Top][All Lists]

[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: Sat, 27 Sep 2014 10:59:25 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

"Stephen J. Turnbull" <address@hidden> writes:

> David Kastrup writes:
>  > Dmitry Antipov <address@hidden> writes:
>  > > 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.
> You can say the same about the Linux kernel, for example.

The last time I looked, Emacs ran on more platforms than GNU/Linux.  We
don't have a tie-in here.

> Nevertheless, the HURD has never made it to ready-for-prime-time
> status.  At some point it's worth delegating maintenance of 99% of
> your needs to another project, and Emacs has already been through the
> Mule-to-Unicode internal encoding conversion.  Would you really wish
> that on another project?

The point is that "GUILE" and "Emacs" are slated to be linked, and that
will not happen if that would seriously degrade Emacs' usability for
working with texts.  It is a core capability of Emacs we are talking
about here.

>  > 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.
> I really doubt it will take much effort to move Emacs to ICU (compared
> to grafting Emacs's complex internal facilities onto another project).

If it would not take much effort, then it should be attempted
independently.  Only in that manner can one properly estimate the
respective performance, footprint, programming and compatibility impacts
independently from those of moving to GUILE.

But that still does not touch the problem of making a core tenet of
Emacs, one where Emacs needs to perform better and more versatile than
most other applications and where we are talking about much more
performance-relevant behavior than for most applications, depend on an
externally controlled and maintained library.

That's a particularly important reason for evaluating an ICU dependency
in a separate branch independent from GUILE first.

David Kastrup

reply via email to

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