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

[Eli Zaretskii]

> Date: Tue, 15 Dec 2015 20:16:03 +0100
> From: Anders Lindgren <andlind@gmail.com>
> Cc: 22169@debbugs.gnu.org
> 
>     I think we should remove that, and leave behind an alias that uses
>     utf-8-hfs, which is provided by Emacs. There's no reason to maintain
>     2 identical definitions.
> 
> Sounds reasonable. The implementation is vastly different, so getting rid of
> one is definitively an improvement.

Can you write a patch to that effect, for emacs-25 branch?

>     What does this return:
>     
>     M-: (file-name-all-completion "åäö" "/that/empty/directory/") RET
> 
> It returns nil.

So this is the heart of the problem.  I assume that if you do the same
with an ASCII first argument, the result is non-nil, yes?

Then the next step is to step with a debugger through
file_name_completion, and see why this returns nil instead of a list
of files that begin.

> Just out of curiosity -- how does `file-name-all-completions' work? Is the 
> FILE
> argument encoded to decomposed form, is the file list converted to composed
> form, or is this handled by the comparison functions?

See dired.c:file_name_completion.  In a nutshell, we do this:

  . 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

The above is for file-name-all-completions; for file-name-completion
the last step is more complicated, but we should understand the
file-name-all-completions case first.

When you step through the code, please pay attention to the encoded
file names.  My guess is that somehow the call to scmp around line 500
fails, or maybe we don't count characters correctly in this case.

Thanks.