Re: guile can't find a chinese named file

[Eli Zaretskii]

> From: Marko Rauhamaa <address@hidden>
> Cc: address@hidden
> Date: Thu, 16 Feb 2017 09:16:21 +0200
> 
> If I understood it correctly, someone just told us emacs maps illegal
> UTF-8 to another form of illegal UTF-8 and back. That's better in that
> it's bytes to bytes (leaving Unicode out), but it's not immediately
> obvious to me why you have to transform the byte sequence at all.

Because it allows to solve all the problems you raise in the rest of
this thread.

> Look at the problem of concatenation. We could have a case where two
> illegal UTF-8 (or UTF-16) snippets are concatenated to get valid UTF-8
> (or UTF-16). That operation fails if you try to translate the snippets
> to strings before concatenation. Such concatenation operations are
> commonplace when dealing with filenames (eg, split(1)).

You assume that Emacs concatenates strings by just splicing its bytes.
But that's a far cry from what Emacs does, precisely to countermand
such problems.  I think David described enough of what's happening to
explain why Emacs is not susceptible to such failures.

These tricks, which all happen seamlessly and transparently, are
exactly why it took Emacs so long to get where it is today.  It takes
many moons to see the problems, analyze them, devise solutions that
don't break, and implement both the 90%-successful heuristics and the
opt-in solutions for the other 10%.  The important point for Guile is
that the solution is there, in Free Software, documented well enough,
and people who understand the implementation and can explain its
subtleties are still here, ready to help.  All it takes is for Guile
to decide it wants to implement something similar.