bug#22169: 25.0.50; File name compiletion doesn't work with non-ASCII characters on OS X

[Random832 <random832@fastmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:
>   . encode the file argument
>   . encode the directory argument and pass it to opendir
>   . loop calling readdir, and for each file name it returns:
>     . if the file name begins with the same characters as the encoded
>       file argument, then:
>       . decode the file name
>       . cons the decoded name onto the list to be returned

My guess from the symptoms is that utf-8-nfd doesn't actually
bother to make any attempt to convert to decomposed form when
encoding, since in *most* cases e.g. for opening a file, the
underlying filesystem will take care of this automatically.

This is backed up by the fact that, looking at the code, it
apparently has a post-read-conversion but no matching
pre-write-conversion.

Anders Lindgren writes:
> I tried setting it to nil. This made completion work. However,
> the letters are presented in decomposed form, so that pressing
> backspace first converts "å" to "a", a second backspace
> deletes the "a" -- this is not how we would like to present
> file names to users.

Why? That _is_, for better or worse, the filename on the
disk.  On a non-OSX system, someone might actually have such a
filename, distinct from the composed one.

For that matter, what happens if an OSX user saves or opens a
file on a non-HFS filesystem? Can Emacs handle the concept of
different filesystems having different encodings?

Ultimately, this isn't really an encoding - it is a destructive
folding operation performed by the filesystem (the same as if,
say, some filesystem stored filenames in all uppercase), and
we've decided, for some reason, that we want the filenames back
in what we've judged to be more likely to be the original form.