Re: guile can't find a chinese named file

[Mike Gran]

On Monday, January 30, 2017 7:31 PM, Eli Zaretskii <address@hidden> wrote:

> Latin-1 has holes in the 0..255 range, so it isn't very appropriate in
> this situation.

I was being imprecise. 
Internally, in Guile, if a string consists of 
Unicode codepoints zero to 255, it is stored as what Guile calls a 
"narrow" string.
 This is still true in 2.1.x, I think.

The first 256 codepoints of Unicode consists of C0 controls, the 
US-ASCII set, the C1 controls from ECMA-48, and the right hand part 
of Latin-1.

In early 2.0.x Guile versions, before setlocale was called, Guile would
map unspecified 8-bit clean file paths to this 8-bit encoding
that consisted of the first 256 codepoints in the Unicode standard.  

> Emacs stores all environment variables in their original
> locale-specific encoding, as unibyte strings, and only decodes them
> when they are actually used or handed to Lisp.
Another method is that of Perl6 where all strings are utf8.
In Perl6 on MoarVM it assumes all
environmental variables and strings are UTF-8, unless otherwise specified,
but it uses their UTF-8-c8 encoding that can encode/decode invalid
UTF-8.