GNU bug report logs - #49776
28.0.50; Incorrect username completion results reported by `read-file-name-interal`

Previous Next

Full log

Message #37 received at 49776 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 49776 <at> debbugs.gnu.org
Subject: Re: bug#49776: 28.0.50; Incorrect username completion results
 reported by `read-file-name-interal`
Date: Fri, 30 Jul 2021 17:45:22 -0400

Lars Ingebrigtsen [2021-07-30 19:18:53] wrote:
> Daniel Mendler <mail <at> daniel-mendler.de> writes:
>> I am not looking at this as a user. I am investigating odd completion
>> results in my Vertico completion UI (on GNU ELPA), when completing file
>> names. If you type "~/etc/~man", you see these odd candidates
>> "/etc/~man", where "/etc/" is actually part of the shadowed path. So to
>> say it differently, I don't expect the shadowed path to take part in the
>> completion.
>
> Ah, right.
>
>> Maybe Stefan can chime in here and explain some of the background. I've
>> corresponded with him before a few times regarding how the completion
>> machinery works internally.
>
> Right.  Stefan, in short -- the thing we're wondering is whether this is
> correct: 
>
> (read-file-name-internal "~/foo/~man" nil t)
> => (#("/foo/~man/" 0 9 (face completions-common-part)))

Yup,. that's wrong.

> (read-file-name-internal "./foo/~man" nil t)
> => (#("man/" 0 3 (face completions-common-part)))

This one looks right.

> I'd kinda expect both to give the same result (i.e., the latter result)?

Agreed.


        Stefan

Previous Next

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