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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 18 Dec 2015 07:29:17 +0100
> From: Anders Lindgren <andlind@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, random832@fastmail.com
> 
> After reading through Random832:s comments, I also see the problem with "åäö"
> and "aao" not being handled correctly. Typing "a TAB" makes Emacs delete the
> "a", which seems very confusing. Typing "å TAB" or "aa TAB" works, though.
> (Here `(file-name-all-completions "a" ".")' returns `("åäöfirst.txt"
> "aaosecond.txt")'.
> 
> In other words, Emcas is in better shape with my than it was before, but there
> is still some work to be done.
> 
> When it comes to "lax" matching -- I really don't think we should use it for
> file names. I don't want to match "å" when I type "a" etc.

I have an idea for a change that could solve this.  I will post it in
a day or two and ask you to try it.

> HFS+ file systems are case sensitive (It's possible this can be disabled, but
> if so it's very rarely used). However, many OS X desktop applications work hard
> to make this invisible to users. I think that we should keep
> `read-file-name-completion-ignore-case' as it is, as this corresponds to how
> files really are stored.

If that's what OS X users expect, fine with me.

> After giving this some thought, it feels like the file name matching should be
> done on decoded strings (so that an "a" doesn't match the "a" in a decomposed
> "å"). However, this is a major change and needs to be discussed further.

I rather think it's a non-starter, at least for Emacs 25.1.  It
probably means users of all systems will be punished by slower
directory searches, on behalf of one peculiar filesystem.  Unless
there's some clever idea that avoids decoding each file name returned
by readdir, that is.

Thanks.