GNU bug report logs - #60264
29.0.60; Strange file completion candidates for shadowed file paths

Previous Next

Package: emacs;

Reported by: Daniel Mendler <mail <at> daniel-mendler.de>

Date: Thu, 22 Dec 2022 20:59:02 UTC

Severity: normal

Found in version 29.0.60

Full log


View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, Eli Zaretskii <eliz <at> gnu.org>, 60264 <at> debbugs.gnu.org
Subject: bug#60264: 29.0.60; Strange file completion candidates for shadowed file paths
Date: Tue, 27 Dec 2022 00:16:13 +0000
This bug was an opportunity to take another journey in the completion 
routines.  Call me a masochist.

The bug here (with the "C-x C-f //etc//s TAB" recipe) is that, in 
completion--twq-all, qboundary is set to 1 instead of 7, because 
(completion--sifn-requote 1 "//etc//s") returns 1 although 
(completion--sifn-requote 1 "~/etc//s") returns 7, because 
(string-prefix-p "/" (substitute-in-file-name "~/")) is nil although 
(string-prefix-p "/" (substitute-in-file-name "//")) is t.

And now I'm lost, because I don't see any safe way to correct that bug. 
completion--sifn-requote seems to work "as designed", and introducing a 
specific treatment for this case would break the "treat 
substitute-in-file-name as a black box as much as possible" rule. 
Perhaps the fix should go into completion--twq-all instead, but again I 
don't see how to do that in a safe way.

Stefan, do you see anything in your legendary crystal ball?





This bug report was last modified 2 years and 172 days ago.

Previous Next


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