Re: Emacs rewrite in a maintainable language

[Ludovic Courtès]

Eli Zaretskii <address@hidden> skribis:

>> From: address@hidden (Ludovic Courtès)
>> Date: Fri, 16 Oct 2015 14:03:39 +0200
>> 
>> David Kastrup <address@hidden> skribis:
>> 
>> > This needs an overhaul of GUILE's string handling (which delegates parts
>> > of it to helper libraries, some of those being under control of GNU,
>> > some not).
>> 
>> String handling is partly delegated to GNU libunistring.  There’s no
>> other library involved.
>
> Yes, but libunistring is not a good basis for Emacs's i18n features,
> because it relies on the underlying C library for most of its
> features.  That doesn't allow writing programs that behave exactly the
> same on any platform, something that Emacs must support.  It also is
> too locale-dependent, which is a Bad Thing on platforms which don't
> have the glibc new-locale feature (and is IMO inelegant in use even on
> glibc platforms).

Well yes, libguile relies on things like iconv, either via libunistring
or directly.  Locale-dependent code is limited to the (ice-9 i18n)
module, which is about locales.

I don’t think it’s the end of the world, though.  Emacs could pretty
much keep using its own text I/O routines if those of Guile don’t fit
the bill.

> Another minor point is that Guile still doesn't allow to control the
> EOL format of text I/O independently of binary I/O mode, again
> something that Emacs must (and does) have.

Guile’s I/O ports could be extended to handle that, but again, even if
they don’t, Emacs could do its own thing.

I doubt there are major blockers.  Surely things will need to be tweaked
here and there, but only hacking can tell.  :-)

Ludo’.