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

[Eli Zaretskii]

> Date: Sun, 20 Dec 2015 20:16:29 +0100
> From: Anders Lindgren <andlind@gmail.com>
> Cc: random832@fastmail.com, 22169@debbugs.gnu.org
> 
> Unfortunately, it still doesn't work, the "a" is still deleted. You can see
> what happens here:
> 
> (file-name-all-completions "" ".")
> ("åäö.txt" "aao.txt" "../" "./")
> 
> (file-name-all-completions "a" ".")
> ("åäö.txt" "aao.txt") <= Incorrect result

So something's wrong with the patch I wrote, because it was supposed
to reject "åäö.txt" in the last case.  Can you see why it didn't?

> I gave this a bit of thinking, would the following work:
> 
> - For each match of the current system (using encoded comparison), after the
> decoding of the entry, perform a second comparison with the decoded (original)
> version of "file" (when not empty).
> 
> There is no extra decoding included, as the number of entries decoded is the
> same as before (even if some entries will be rejected now). The extra
> comparison is only performed if "file" is not empty, so it will not affect
> normal directory retrieval, only when performing a completion operation.
> 
> Concretely, in the example above, completing "a" will find both entries which
> are decoded. However, the second comparison will reject "åäö.txt".

That's exactly what my patch was supposed to do -- it makes a second
comparison right before adding a candidate to the result.  If you can
see why it isn't working, we can take it from there.

Thanks.