Re: Emacs rewrite in a maintainable language

[Eli Zaretskii]

> From: address@hidden (Ludovic Courtès)
> Cc: address@hidden
> Date: Sat, 17 Oct 2015 11:44:25 +0200
> 
> >> My point is: Emacs can keep doing its own thing in that area.
> >
> > Of course.  But that takes away a serious chunk of arguments in favor
> > of Guile-based Emacs, for 2 reasons: (a) there will have to be a
> > non-trivial translation layer between the two, and (b) a very large
> > part of Emacs's C core will have to be left intact, instead of
> > removing it because Guile already does that.
> 
> AFAIK nobody claims that Guile is the right choice due to its i18n
> support.
> 
> The main claims are: the compiler, VM (which would no longer be part of
> Emacs), FFI, libraries, etc.
> 
> That chunk isn’t taken away.

I agree.  But those features are additions to what Emacs already has.
They are advantages for the future.  This thread talks about a
"rewrite", i.e. about replacing the existing C code with something
that will be more maintainable and will attract new developers easier
than the current C core.  With that perspective, advantages for the
future are less relevant; what is more relevant is how much of the
current C core could be replaced by Guile, and how much will have to
be rewritten in Guile Scheme or left in C.

> Guile strings are fine, thank you.  I’ve used a bunch of
> language/environments and honestly, I’m definitely not ashamed of what
> Guile provides, contrary to what David and you seem to imply.

I didn't mean to imply that Guile development should be ashamed.  But
please consider this: the first version of Emacs i18n was released
with Emacs 20.1.  People who designed and implemented it were not
stupid, and the result was nothing to be ashamed of, either: it solved
a very large part of the problem it was intended to solve.  And yet
since then the v20.1 implementation on various levels was
significantly changed no less than 2 times, in response to real-life
experience and user feedback.  If we speak today about some
non-trivial conclusions drawn from that, we are speaking armed with
that experience.

Guile's i18n is today where Emacs was at v20.1, with the (important)
difference that its internal representation is based on Unicode and
UTF-8.  The lessons of Emacs development since then till today are yet
to be learned and incorporated into Guile.  I really think Guile
developers should seriously study the Emacs experience, if Guile is
supposed to support multi-lingual environments.

For example, IMO Guile relies too much on the underlying libc, in
particular on the locale-dependent services libc provides.  A
multi-lingual text-processing environment such as Emacs cannot depend
on locales, because each locale supports only one language.  Emacs
includes support for multiple languages in the same buffer/file that
simply cannot be easily implemented using locale-dependent features.
By contrast, Guile is quite good in supporting a single language, but
not as good when several different languages/scripts are to be mixed
in the same string.  E.g., consider a simple problem of counting
characters in such a string -- the libc functions like mbslen are not
guaranteed to support this outside of the current language/locale.