Re: I cannot run make check since Issue 5450: relocate.cc: Introduce new command `set?'

[David Kastrup]

Valentin Villenave <address@hidden> writes:

> On 1/24/19, David Kastrup <address@hidden> wrote:
>> texi2html(?) does have specific version requirements
>
> Yes, I meant texi2html! We’re in a bind similar to that of Guile: the
> old unmaintained version works and not the new one. (Well, minus the
> outrageous 
> let’s-drop-non-ASCII-strings-support-because-frankly-who-needs-those
> situation with Guile 2.x.)
>
> (I may be mistaken, but that’s what I gathered in a nutshell.)

No, Guile-2.0 fully supports Unicode.  Which is sort of the problem.
Its strings are either UCS-32 or Latin-1 internally.  Its string API,
however, is either UTF-8 or Latin-1.  So in practice, getting anything
but Latin-1 into Guile and out again causes conversions to happen
internally.  The conversions are not byte-preserving when non-canonical
UTF-8 is involved.  Guile has string buffers (I/O from/to internal
strings).  The string buffers are encoded in UTF-8.  So even when
processing strings entirely internal of Guile, conversions are involved.
String buffer indexes are byte counts, string indexes character counts.

So it supports Unicode, but internals are leaking everywhere and data
cannot be passed externally and even internally without conversions.

Basically they repeat all the mistakes of Emacs-20 (the version that
caused the last large migration to XEmacs in order to escape performance
and reliability problems connected with an early multibyte
implementation) and then some.  They have a fraction of the man power
working on current Guile versions (try finding any commits _not_ made by
Andy Wingo that aren't forward ports of bug fixes in the stable
versions) and nobody will admit that there is any problem worth working
on, so when it took Emacs 10 years to return to front row after turning
multibyte, I don't see that Guile will make it in 30.

Unless they make Guilemacs (implementing Emacs and Emacs Lisp on top of
Guile _and_ making this the default for Emacs) a priority.  Because the
Emacs developer and user base will not stand for returning to the
darkest parts of Emacs history.

In contrast, Guile-1 only supports byte strings/streams and we are
responsible for all the rest.  Which means that no conversions happen in
the API, and any conversions happen under own control.  For native
string processing in Scheme, that is sort of a nuisance.  But a fraction
of the nuisance that the "full Unicode support" of Guile-2 is.

-- 
David Kastrup