On Monday, January 30, 2017 12:00 PM, Eli Zaretskii <e...@gnu.org> 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
