bug#15260: cannot build in a directory with non-ascii characters

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: rgm@gnu.org,  Kenichi Handa <handa@gnu.org>,  15260@debbugs.gnu.org
> Date: Sun, 27 Oct 2013 00:28:36 -0400
> 
> I don't understand why it wouldn't work to just treat those strings as
> "binary" (i.e. keep them undecoded in unibyte strings).  Then encoding
> would be a noop and that should hence end up in the right byte-sequence
> sent to the OS primitives.

Not sure I'm following you here.  I presume you aren't asking why we
generally hold file names in decoded form inside Emacs, nor suggesting
that we switch to storing them as undecoded unibyte strings.

So I guess you are asking why the particular piece of code being
discussed here couldn't keep file names as unibyte strings, is that
your question?

If so, then the answer is "it could, but that would be even more
hair."

The problem is that the code involved in this (specifically,
init_callproc_1, init_callproc, and probably also init_cmdargs and
init_lread) is not something specifically written to stat the
directories from epaths.h and announce their non-existence.  That code
populates important variables with names of files and directories and
lists of directories that are henceforth used in Emacs all over the
place.  Notable examples are data-directory, doc-directory, exec-path,
and load-path.  Without populating these variables, temacs will not
work, and the code which uses these variables assumes their values are
decoded strings.

The error messages are a by-product: as Emacs computes the values of
these variables, it checks the files and directories for existence,
and complains if they don't.  The root cause is that unibyte strings
get stored in variables used by Emacs on the assumption that they are
decoded.

Given the above, I'm not sure exactly what you are suggesting in
practical terms.  Can you elaborate?