bug#15803: default-file-name-coding-system: utf-8 better than latin-1 these days?

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: rgm@gnu.org,  15803@debbugs.gnu.org
> Date: Fri, 11 Sep 2020 12:55:55 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> All the tools under Linux are so utf-8-focused these days...  let's
> >> see...  I first, under a utf-8 locale created the directory "émacs",
> >> then converted it to 8859-1:
> >
> > No, please create the directory with non-ASCII name _after_ switching
> > the locale to Latin-1.
> 
> Shouldn't the result be the same?  I.e., a name with iso-8859-1 name?

No, because the Linux file I/O APIs are encoding-agnostic, they will
(AFAIK) create the directory with a name that is the exact byte stream
that you type at the mkdir command (or at the Emacs make-directory).

> The reason I did it this convoluted name was just that I couldn't
> convince my system to make a 8859 name even after changing the locale.
> That is, when I typed Alt-gr ' e, my terminal still sent over two bytes
> (i.e., in utf-8) instead of a single-byte é.

Try doing this in Emacs, and use one of the Latin input methods if the
keyboard doesn't cooperate.

> But I think I know why "make check" was failing:
> 
> [larsi@stories ~/src/emacs/trunk]$ echo $LANG
> sv_SE.ISO-8859-1
> [larsi@stories ~/src/emacs/trunk]$ echo $LANG
> en_US.UTF-8

I don't understand this: 2 identical commands one after the other
yield different results?

> The tests that were failing all talked about "chmod" and stuff, so I'm
> guessing they were from a sub shell, and my system is apparently forcing
> all new shells to use UTF-8...

Really?  So there's no way to change the locale to something
non UTF-8?

> make check:
> 
> >>Error occurred processing lisp/eshell/eshell-tests.el: File is missing 
> >>(("Doing chmod" "No such file or directory" 
> >>"/home/larsi/src/emacs/f\303\263o/test/lisp/eshell/eshell-tests.elcgtybBC"))
> 
> This time over, the directory is "fóo" (in latin-1), and that looks like
> Emacs is trying to find the utf-8 version of the file name.

If that's the case, then we lack ENCODE_FILE (or more generally don't
encode a file name) somewhere.

> So it looks like the patch set has problems, and needs further fixes.
> (Or "make check" has some problems here, since Emacs otherwise seems to
> work fine.)

We could also just install the changes and wait for bug reports, on
the assumption that the problems you see aren't real.  Your call.