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

[Random832 <random832@fastmail.com>]

Anders Lindgren <andlind@gmail.com> writes:
> Below is a patch where I have dropped the old encoder and use the new
> instead. The only thing noteworthy is that `ucs-normalize' is loaded
> by loadup (when ns is used) and thus included in the dumped Emacs (if
> I understand correctly). Unless anybody objects, I'll push it in a
> couple of days.

Out of sheer morbid curiosity, I decided to see what happens if
I create a filesystem with both NFC and NFD characters (For
thoroughness, I tested both colliding and non-colliding names,
on FAT32 and NFS.

On a FAT32 volume, Linux creates all of them fine, obviously.
OSX completely fails to do anything meaningful with the files
that are in NFD on disk: They are returned by readdir, but
cannot be opened or statted (opening one that has a name
collision with an NFC file opens the NFC file).  To my under-
standing the same behavior would be present for SMB and UDF
volumes.  The filenames are normalized to NFD when returned by
readdir, but only the filenames that are normalized to NFC on
disk are accessible.

On NFS, the story is a bit more interesting. OSX does not
perform any normalization on filenames on an NFS share.  After
being bitten by a similar bug in zsh's globbing, I was able to
determine that Emacs is able to open and save files in both
formats with utf-8-nfd (since encoding passes values through
unchanged), but _not_ with utf-8-hfs.

Arguably, for the rare users who use NFS or other filesystems
and work with characters whose representations differ, they can
simply use the utf-8 encoding and be explicit about what
filenames they want.  It is something to be aware of, though.