[Top][All Lists]

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

Re: Perception of LilyPond development status

From: David Kastrup
Subject: Re: Perception of LilyPond development status
Date: Tue, 17 Dec 2019 13:15:32 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Jacques Menu <address@hidden> writes:

> Hello David,
> Maybe this is totally stupid, but would it be meaningful to pick a
> Guile 2 version, fix the issues in string
> implementation and design, and freeze that fixed version for Lily’s
> own use, without depending on Andy Wingo’s work for some time?

That "fix" would consist in making Guile strings UTF-8 only.  Throw out
everything else.  Problem is that Scheme has in-place string
manipulations that don't work with variable-size characters.  It may be
that recent Scheme standards have tried to become more UTF-8 friendly,
no idea.

A beyond-LilyPond fix would turn the internal string coding into some
extension of UTF-8 like Emacs does.  That is actually also a
prerequisite of making something like Guilemacs ever take off.  Getting
Emacs' string implementation to its current quality took decades.

A few seminal points:

Code points for large characters are supported (at one point 32-bit
characters, but it may be reduced to the theoretic maximum with 4-byte
characters these days).  Out-of-sequence bytes from 128–255 are
represented with 2-byte sequences (overlong representations of 0–127 not
valid as UTF-8), valid UTF-8 is represented as itself.  That makes any
binary data representable with a blow-up factor of at most 2.

With Emacs, the details are in the various encoding itty-bitties: the
internal processing is comparatively straightforward.  Buffers are
addressed by character positions, not bytes.

The itty-bitty details mostly concern conversion into/out of the
internal UTF-8 though and don't have much of an impact on the normal

David Kastrup

reply via email to

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