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

Previous Next

Full log

View this message in rfc822 format

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

On 7/30/21 3:12 PM, Lars Ingebrigtsen wrote:
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> 
>> (all-completions "~/.config/~notexist" #'read-file-name-internal)
>> => nil
> (read-file-name-internal "~/.config/~notexist" nil t)
> => nil

Yes, this is what I expect. I see the same.

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

I see this too and it may be correct behavior. But then I wonder why the
completion boundaries are placed as they are.

> and note that this is an internal function not to be used by users.

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.

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.

Daniel

Previous Next

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