Re: Emacs rewrite in a maintainable language

[Eli Zaretskii]

> From: Wolfgang Jenkner <address@hidden>
> Cc: address@hidden (Ludovic Courtès),  address@hidden
> Date: Fri, 16 Oct 2015 16:55:37 +0200
> 
> On Fri, Oct 16 2015, Eli Zaretskii wrote:
> 
> > 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.  
> 
> IIUC, the behaviour of the recently added `string-collate-lessp' and
> `string-collate-equalp' already depends on libc (and the locale data).

Yes, but these two functions are not called by anything else, they
exist so Lisp applications could use locale-specific collation data.

I wasn't talking about that, I was talking about stuff like decoding a
Latin-1 file into the internal UTF-8 based representation of
characters, or vice versa.  Emacs does that all the time.  What
libunistring does is call the libc's mbstowc, or some such.  That
requires libc to support all the encodings Emacs needs to support,
which I think doesn't happen even with glibc, let alone other system
libraries.

> (Lest this be interpreted as criticism: IMHO, depending on POSIX
> facilities is a good thing, even for emacs.)

Emacs should first and foremost present the same behavior and
capabilities on all platforms.  Different platforms implement Posix to
different degrees, so relying on Posix capabilities provided by the
platform has its limits, and interferes with the above goal of
presenting the same behavior.

Basing i18n on locale-specific behavior is especially wrong.