emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs rewrite in a maintainable language


From: Taylan Ulrich Bayırlı/Kammer
Subject: Re: Emacs rewrite in a maintainable language
Date: Sat, 17 Oct 2015 19:00:03 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

David Kastrup <address@hidden> writes:

> address@hidden (Taylan Ulrich "Bayırlı/Kammer") 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.

Maybe one could say GuileEmacs does indeed scrap any string handling in
Guile, since it simply uses the existing Elisp string data type.

I guess the problem for LilyPond was that it used to use the Guile 1
string data type which now doesn't exist anymore?  Thankfully no such
problem applies to GuileEmacs which can just stick to Elisp strings.


(I think I need to take back the "none of the current problems are
related to strings" though, since IIRC Elisp strings can't currently be
serialized into Guile's byte-code to be written onto the disk.  Not sure
if that's relevant to the topic.)

Taylan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]