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

Previous Next

To reply to this bug, email your comments to 60264 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.60; Strange file completion candidates for shadowed file paths
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.

In GNU Emacs 29.0.60 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.16.0, Xaw scroll bars) of 2022-12-11 built on projects
Repository revision: f221105723dc8d3ee9f3c8d1c2717058afbc6666
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description: Debian GNU/Linux 10 (buster)

Message #8 received at 60264 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 60264 <at> debbugs.gnu.org
Subject: Re: bug#60264: 29.0.60;
 Strange file completion candidates for shadowed file paths
Date: Fri, 23 Dec 2022 09:13:46 +0200

> From: Daniel Mendler <mail <at> 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.

Message #11 received at 60264 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 60264 <at> debbugs.gnu.org
Subject: Re: bug#60264: 29.0.60; Strange file completion candidates for
 shadowed file paths
Date: Fri, 23 Dec 2022 09:02:25 +0100

On 12/23/22 08:13, Eli Zaretskii wrote:
>> From: Daniel Mendler <mail <at> 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

Message #14 received at 60264 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 60264 <at> debbugs.gnu.org
Subject: Re: bug#60264: 29.0.60; Strange file completion candidates for
 shadowed file paths
Date: Fri, 23 Dec 2022 09:08:37 -0500

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

He's right, that's a bug.  *Completions* normally only shows the list of
matching files in the final directory, so complete filenames.  It's even
more true here where the "excess" is not even really part of the file
name since it'll be stripped away by `substitute-in-file-name`.

E.g. if you replace "/etc//s" with "~//s" in the example, we show the
correct list.


        Stefan

Message #17 received at 60264 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#60264: 29.0.60; Strange file completion candidates for
 shadowed file paths
Date: Fri, 23 Dec 2022 17:38:08 +0000

>>> 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.
>
> He's right, that's a bug.  *Completions* normally only shows the list of 
> matching files in the final directory, so complete filenames.  It's even 
> more true here where the "excess" is not even really part of the file 
> name since it'll be stripped away by `substitute-in-file-name`.
>
> E.g. if you replace "/etc//s" with "~//s" in the example, we show the 
> correct list.
>

It's a bug indeed, but a very old one, it's also present in Emacs 
24-25-26-27-28.

Message #20 received at 60264 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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?

Previous Next

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