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

From: Eli Zaretskii <[email-masked]>
Date: Wed, 16 Dec 2015 05:32:56 +0200

> From: Random832 <[email-masked]>
> Date: Tue, 15 Dec 2015 16:53:37 -0500
> 
> Eli Zaretskii <[email-masked]> 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.