* bug#59803: completion-at-point in shell buffer ignores some files
@ 2022-12-03 11:01 Nicolas Graner
2022-12-04 9:58 ` Eli Zaretskii
0 siblings, 1 reply; 7+ messages in thread
From: Nicolas Graner @ 2022-12-03 11:01 UTC (permalink / raw)
To: 59803
In a *Shell* buffer, file name completion ignores file names already
present on the current line. For example, if you have a file named `foo'
and no other file starting with an f, when you type:
$ cp f<TAB> f<TAB>
the first <TAB> completes `f' to `foo', but the second <TAB> gives a `No
match' error.
Similarly, if you have files named foo1, foo2, foo3 and foo4, then:
$ mv foo1 foo2 f<TAB>
shows only foo3 and foo4 in the completions buffer.
Happens in emacs 29 but not in 28.
Nicolas
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#59803: completion-at-point in shell buffer ignores some files
2022-12-03 11:01 bug#59803: completion-at-point in shell buffer ignores some files Nicolas Graner
@ 2022-12-04 9:58 ` Eli Zaretskii
2022-12-10 12:51 ` Eli Zaretskii
0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2022-12-04 9:58 UTC (permalink / raw)
To: Nicolas Graner, Stefan Monnier; +Cc: 59803
> From: Nicolas Graner <nicolas@graner.name>
> Date: Sat, 03 Dec 2022 12:01:16 +0100
>
> In a *Shell* buffer, file name completion ignores file names already
> present on the current line. For example, if you have a file named `foo'
> and no other file starting with an f, when you type:
>
> $ cp f<TAB> f<TAB>
>
> the first <TAB> completes `f' to `foo', but the second <TAB> gives a `No
> match' error.
>
> Similarly, if you have files named foo1, foo2, foo3 and foo4, then:
>
> $ mv foo1 foo2 f<TAB>
>
> shows only foo3 and foo4 in the completions buffer.
>
> Happens in emacs 29 but not in 28.
This seems to be due to some changes in pcomplete.el since Emacs 28, because
if you remove pcomplete-completions-at-point from the value of
shell-dynamic-complete-functions, the problem goes away.
Stefan, can you help here? It sounds like the culprit is some of the
changes in commit 0a36671f41 and/or 88b025f815, but I'm not sure.
Thanks.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#59803: completion-at-point in shell buffer ignores some files
2022-12-04 9:58 ` Eli Zaretskii
@ 2022-12-10 12:51 ` Eli Zaretskii
2022-12-10 21:43 ` Gregory Heytings
0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2022-12-10 12:51 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 59803, nicolas
Ping! Stefan, any suggestions or ideas?
> Cc: 59803@debbugs.gnu.org
> Date: Sun, 04 Dec 2022 11:58:43 +0200
> From: Eli Zaretskii <eliz@gnu.org>
>
> > From: Nicolas Graner <nicolas@graner.name>
> > Date: Sat, 03 Dec 2022 12:01:16 +0100
> >
> > In a *Shell* buffer, file name completion ignores file names already
> > present on the current line. For example, if you have a file named `foo'
> > and no other file starting with an f, when you type:
> >
> > $ cp f<TAB> f<TAB>
> >
> > the first <TAB> completes `f' to `foo', but the second <TAB> gives a `No
> > match' error.
> >
> > Similarly, if you have files named foo1, foo2, foo3 and foo4, then:
> >
> > $ mv foo1 foo2 f<TAB>
> >
> > shows only foo3 and foo4 in the completions buffer.
> >
> > Happens in emacs 29 but not in 28.
>
> This seems to be due to some changes in pcomplete.el since Emacs 28, because
> if you remove pcomplete-completions-at-point from the value of
> shell-dynamic-complete-functions, the problem goes away.
>
> Stefan, can you help here? It sounds like the culprit is some of the
> changes in commit 0a36671f41 and/or 88b025f815, but I'm not sure.
>
> Thanks.
>
>
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#59803: completion-at-point in shell buffer ignores some files
2022-12-10 12:51 ` Eli Zaretskii
@ 2022-12-10 21:43 ` Gregory Heytings
2022-12-11 15:06 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 7+ messages in thread
From: Gregory Heytings @ 2022-12-10 21:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Stefan Monnier, 59803, nicolas
[-- Attachment #1: Type: text/plain, Size: 165 bytes --]
I'm not Stefan (alas 😉), but the culprit is a994126968, and here's the
fix (a single character change!).
>
> Ping! Stefan, any suggestions or ideas?
>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Do-not-pare-arguments-unnecessarily.patch --]
[-- Type: text/x-diff; name=Do-not-pare-arguments-unnecessarily.patch, Size: 921 bytes --]
From 7df86f7dfab69dd6ffa2625bbe2584d70e9c9242 Mon Sep 17 00:00:00 2001
From: Gregory Heytings <gregory@heytings.org>
Date: Sat, 10 Dec 2022 21:40:31 +0000
Subject: [PATCH] Do not pare arguments unnecessarily.
* lisp/pcomplete.el (pcomplete-here-using-help): Do not pare
arguments. Fixes bug#59803.
---
lisp/pcomplete.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lisp/pcomplete.el b/lisp/pcomplete.el
index ef286b70fe..e01f42ceb4 100644
--- a/lisp/pcomplete.el
+++ b/lisp/pcomplete.el
@@ -1456,7 +1456,7 @@ pcomplete-here-using-help
(pcomplete-match-string 1 0)))
((string-prefix-p "-" (pcomplete-arg 0))
(pcomplete-here (apply #'pcomplete-from-help command args)))
- (t (pcomplete-here (pcomplete-entries))))))
+ (t (pcomplete-here* (pcomplete-entries))))))
(provide 'pcomplete)
--
2.35.1
^ permalink raw reply related [flat|nested] 7+ messages in thread
* bug#59803: completion-at-point in shell buffer ignores some files
2022-12-10 21:43 ` Gregory Heytings
@ 2022-12-11 15:06 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-11 15:15 ` Eli Zaretskii
0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-12-11 15:06 UTC (permalink / raw)
To: Gregory Heytings; +Cc: Eli Zaretskii, nicolas, 59803
> I'm not Stefan (alas 😉), but the culprit is a994126968, and here's the fix
> (a single character change!).
Not sure how I failed to see your message, but I just tracked the
problem to the same source. Thanks, the patch looks just right.
Stefan
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#59803: completion-at-point in shell buffer ignores some files
2022-12-11 15:06 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-12-11 15:15 ` Eli Zaretskii
2022-12-12 1:04 ` Gregory Heytings
0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2022-12-11 15:15 UTC (permalink / raw)
To: Stefan Monnier; +Cc: gregory, nicolas, 59803
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>, 59803@debbugs.gnu.org, nicolas@graner.name
> Date: Sun, 11 Dec 2022 10:06:21 -0500
>
> > I'm not Stefan (alas 😉), but the culprit is a994126968, and here's the fix
> > (a single character change!).
>
> Not sure how I failed to see your message, but I just tracked the
> problem to the same source. Thanks, the patch looks just right.
Gregory, please install on the release branch, and thanks (to both of
you).
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-12-12 1:04 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-12-03 11:01 bug#59803: completion-at-point in shell buffer ignores some files Nicolas Graner
2022-12-04 9:58 ` Eli Zaretskii
2022-12-10 12:51 ` Eli Zaretskii
2022-12-10 21:43 ` Gregory Heytings
2022-12-11 15:06 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-11 15:15 ` Eli Zaretskii
2022-12-12 1:04 ` 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).