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

[Eli Zaretskii]

> From: Random832 <random832@fastmail.com>
> Date: Tue, 15 Dec 2015 16:53:37 -0500
> 
> 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.

I certainly see a pre-write-conversion function in ucs-normalize.el:
ucs-normalize-hfs-nfd-pre-write-conversion which calls
ucs-normalize-HFS-NFD-region.  So I'm not sure I understand what you
are saying.