Hi!

I managed to get the attached patch to work (when used in conjunction with
my previous patch).

I've tested:

* C-x C-f a TAB
* (find-file-all-competions "a" ".")

    -- Anders



On Sun, Dec 20, 2015 at 8:39 PM, Eli Zaretskii <eliz@gnu.org> wrote:

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