Re: guile can't find a chinese named file

[Mike Gran]

On Monday, January 30, 2017 12:00 PM, Eli Zaretskii <address@hidden> wrote:
> Actually, the need arises even sooner.  Consider how load-path is set
> up during startup: it starts with the directory from which Emacs was
> invoked, either from argv[0] or by looking up PATH.  Either way, you
> get a file name that is encoded in the locale-specific encoding.  Then
> you cons load-path by expanding file names relative to the startup
> directory.  So you immediately need to be able to create file names
> from directories, check whether a file exists and is a directory,
> etc. -- all of that before you even know in what locale you started,
> so you cannot decode these file names into the internal

> representation, before using them.

Earlier in the 2.0.x release series, Guile had a hack where it started
up in a Latin-1 encoding, which would be capable of storing any
8-bit string of bytes, even if they weren't Latin-1.  I was the author
of the first version of that hack.  Anyway, while it was technically
incorrect, it did get the job done for some of these locale-free
byte string problems.  It could open non-ASCII paths without really
having an encoding, if I recall correctly.


It was an uneasy middle ground, tho.  Error messages with regards
to file names would be mojibake. And string ports were a mess.And what was 
supposed to happen after setlocale was called?


As an aside, GTK and GLIB based applications often use a method where
you may need to set the environment variable G_FILENAME_ENCODING
if your filename encoding is different from your locale encoding.
GTK/GLIB also likes to store strings internally as UTF-8, and will
convert to UTF-8 from either the locale or the G_FILENAME_ENCODING-
specified encoding.

As another aside, OpenBSD removed support for non-UTF8 locales.


-Mike Gran