* bug#60264: 29.0.60; Strange file completion candidates for shadowed file paths
@ 2022-12-22 20:57 Daniel Mendler
2022-12-23 7:13 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Mendler @ 2022-12-22 20:57 UTC (permalink / raw)
To: 60264
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)
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#60264: 29.0.60; Strange file completion candidates for shadowed file paths
2022-12-22 20:57 bug#60264: 29.0.60; Strange file completion candidates for shadowed file paths Daniel Mendler
@ 2022-12-23 7:13 ` Eli Zaretskii
2022-12-23 8:02 ` Daniel Mendler
2022-12-23 14:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 6+ messages in thread
From: Eli Zaretskii @ 2022-12-23 7:13 UTC (permalink / raw)
To: Daniel Mendler, Stefan Monnier; +Cc: 60264
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#60264: 29.0.60; Strange file completion candidates for shadowed file paths
2022-12-23 7:13 ` Eli Zaretskii
@ 2022-12-23 8:02 ` Daniel Mendler
2022-12-23 14:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 0 replies; 6+ messages in thread
From: Daniel Mendler @ 2022-12-23 8:02 UTC (permalink / raw)
To: Eli Zaretskii, Stefan Monnier; +Cc: 60264
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#60264: 29.0.60; Strange file completion candidates for shadowed file paths
2022-12-23 7:13 ` Eli Zaretskii
2022-12-23 8:02 ` Daniel Mendler
@ 2022-12-23 14:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-23 17:38 ` Gregory Heytings
1 sibling, 1 reply; 6+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-12-23 14:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Daniel Mendler, 60264
>> 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
^ permalink raw reply [flat|nested] 6+ messages in thread* bug#60264: 29.0.60; Strange file completion candidates for shadowed file paths
2022-12-23 14:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-12-23 17:38 ` Gregory Heytings
2022-12-27 0:16 ` Gregory Heytings
0 siblings, 1 reply; 6+ messages in thread
From: Gregory Heytings @ 2022-12-23 17:38 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Daniel Mendler, Eli Zaretskii, 60264
>>> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#60264: 29.0.60; Strange file completion candidates for shadowed file paths
2022-12-23 17:38 ` Gregory Heytings
@ 2022-12-27 0:16 ` Gregory Heytings
0 siblings, 0 replies; 6+ messages in thread
From: Gregory Heytings @ 2022-12-27 0:16 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Daniel Mendler, Eli Zaretskii, 60264
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?
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-12-27 0:16 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-22 20:57 bug#60264: 29.0.60; Strange file completion candidates for shadowed file paths Daniel Mendler
2022-12-23 7:13 ` Eli Zaretskii
2022-12-23 8:02 ` Daniel Mendler
2022-12-23 14:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-23 17:38 ` Gregory Heytings
2022-12-27 0:16 ` Gregory Heytings
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).