Valentin Villenave <valen...@villenave.net> writes: > On 1/24/19, David Kastrup <d...@gnu.org> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel