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

[Daniel Mendler]

On 12/23/22 08:13, Eli Zaretskii wrote:
>> From: Daniel Mendler <mail@daniel-mendler.de>
>> Date: Thu, 22 Dec 2022 21:57:39 +0100
>>
>> 1. Start emacs -Q
>> 2. C-x C-f
>> 3. Delete the entire minibuffer input
>> 4. Enter /etc//s
>> 5. Press ?
>>
>> You will see candidates like etc//sbin/. The candidates can get even
>> stranger. If you enter /etc//etc//etc/s then you will get candidates
>> like etc//etc//etc//sbin/. I can reproduce this bug on 27 and 29. I
>> haven't tried 28, but the issue should exist there too.
> 
> I don't think it's a bug (look at what the minibuffer shows in those
> cases), perhaps just a minor aesthetic thing, but I'm adding Stefan in
> case he has comments.

I argue that this is a bug since the etc// and etc//etc//etc strings
belong to the base prefix of file path completions. The base string is
basically the context of completion but should not be replicated in the
candidates itself. This concept of a completion base string (or
completion boundaries) is of course especially relevant for file
completion where the current directory corresponds to the base. The
candidates itself don't carry their path with them.

Note that the content of the minibuffer is valid. The prefixes are
correctly grayed out. These grayed out paths are called shadowed paths
since they allow the user to easily switch directories. I have not
mentioned this in my report, but you should see the gray out when you
reproduce this.

The bug is that file substitution is not applied correctly at some place
within the internal file completion tables. This points to a bigger
internal correctness issue. See the function `substitute-in-file-name`,
which would get rid of the grayed out paths.

Daniel