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

[Random832]

Eli Zaretskii <eliz@gnu.org> writes:
>> 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.

Maybe. I half suspect it was just to make their case mapping
table (which doesn't include entries for the precomposed
characters) smaller.

>> 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.

Whether that ever gets implemented or not, what I meant to
suggest is that a half-baked lax matching that only works for a
small subset of situations and only on one platform is not a
feature worth having at all. And if people really do want it
they can have it today by setting the encoding to utf-8 and
dealing with the backspacing weirdness.

AFAICT the rationale for renormalizing filenames to NFC was that
combining characters couldn't be *displayed* on Carbon Emacs,
rather than there being anything especially undesirable about
the backspacing behavior.

> 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.

Like I said, ns-win's utf-8-nfd doesn't normalize on encode.
I've since confirmed this with encode-coding-string.  I haven't
been able to confirm that ucs-normalize's utf-8-hfs exhibits the
problem behavior.