Re: Emacs rewrite in a maintainable language

[David Kastrup <dak@gnu.org>]

taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:

> David Kastrup <dak@gnu.org> writes:
>
> Most of the benefits in e.g. http://www.emacswiki.org/emacs/GuileEmacs
> apply without having to solve the string problem.  Specifically, from
> the overview section, the first two points and half of the third
> should apply I think.  The third point only halfway because some Guile
> APIs might expect to receive Guile strings, so using them from Elisp
> code would be problematic, but Guile APIs which don't take strings
> should be fine.  Anyway, the first two points are already pretty
> attractive, especially the second.
>
> Whatever language Emacs is written in, the native string library of
> the language will be insufficient, so meh.

Shrug.  C strings are "insufficient" but they don't get in the way.  The
problem with GUILE 2 strings is not that they are insufficient, the
problem is that they are incompatible while not exposing the mechanisms
that would allow working around that incompatibility.

The way around that is to scrap _any_ string handling in GUILE and
instead map Emacs strings to byte vectors (and the related ports).
Which was actually what was recommended to me to do for LilyPond,
leading to me firing off a sequence of bug reports (I think the last one
was closed recently but the respective fix is not yet in any released
version of GUILE): this code has apparently not seen much exercise.  So
even letting GUILE just step aside with regard to encoding/decoding is
something that's not yet to be called reliable and well-tested.

But that at least improves over time since it cannot be called anything
but a bug.  The coding implementation issues, in contrast, are not
considered something where GUILE is in need of change or redesign and/or
where any work would be scheduled or advertised as necessary.

-- 
David Kastrup