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: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>
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 19:18:53 +0200

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

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

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

(And "man" is a valid user in this scenario.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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