|
From: | Anders Lindgren |
Subject: | bug#22169: 25.0.50; File name compiletion doesn't work with non-ASCII characters on OS X |
Date: | Sun, 20 Dec 2015 23:00:40 +0100 |
> 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.
coding2.diff
Description: Text document
[Prev in Thread] | Current Thread | [Next in Thread] |