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 13:19:20 -0500
> 
> 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.

Only if they force decomposition in contexts that have nothing to do
with file names.  Otherwise, they will have to have those large case
tables anyway, for other kinds of text, right?

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

It is generally easier and more convenient to have precomposed
characters, yes.  It's not an accident that no other filesystem does
this kind of decomposition; Windows filesystems actually compose the
characters, AFAIK.

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

Let's hope you are right.