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

[Eli Zaretskii <eliz@gnu.org>]

> From: Random832 <random832@fastmail.com>
> Date: Wed, 16 Dec 2015 11:00:57 -0500
> 
> > It's not really clear what is correct behavior in this case.  On other
> > platforms Emacs will return only a3, but HFS+ stores decomposed
> > characters precisely to allow all 3 to match.  So I think we should
> > at least cause Emacs return only a3, and ideally also support the
> > other behavior as an option.
> 
> I'm not aware of any published rationale for the decision to
> store decomposed characters.

It cannot be anything other than the desire to support lax matches.

> I think maybe lax matching as an option would be better than
> blindly doing comparisons based on the decomposed form.

It could be, if we had the lax matching implemented in C.  But we
currently only emulate that with complex regexps, and I think it's not
a good idea to call that from dired.c.

> I'm not sure there's a way around it if we want to be 100%
> correct and consistent, given the existence of parts of the
> completion system that do work with the strings in Unicode.

I could come up with a patch if someone's interested to try it.  I
just want to hear first about the details of what happens in
file_name_completion that causes file-name-all-completions return nil
in the OP's case.  There's got to be something that I'm missing here.