Subject: Re: bug#60264: 29.0.60; Strange file completion candidates for shadowed file paths

From: Gregory Heytings <[email-masked]>
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?