Re: Emacs Lisp's future

[David Kastrup <dak@gnu.org>]

Robin Templeton <robin@terpri.org> writes:

> Kristian Nygaard Jensen <freeduck@member.fsf.org> 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:
> <http://permalink.gmane.org/gmane.lisp.ecl.general/10264>. 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
<URL:http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18520> 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