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

Previous Next

Full log

View this message in rfc822 format

From: Anders Lindgren <andlind <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: random832 <at> fastmail.com, 22169 <at> debbugs.gnu.org
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

[Message part 1 (text/plain, inline)]

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 <at> gnu.org> wrote:

> > Date: Sun, 20 Dec 2015 20:16:29 +0100
> > From: Anders Lindgren <andlind <at> gmail.com>
> > Cc: random832 <at> fastmail.com, 22169 <at> 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.
>

[Message part 2 (text/html, inline)]

[coding2.diff (text/plain, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.