GNU bug report logs - #65089
30.0.50; shell-command filename completion unexpected behavior change

Previous Next

Package: emacs;

Reported by: Mauro Aranda <maurooaranda <at> gmail.com>

Date: Sat, 5 Aug 2023 10:47:02 UTC

Severity: normal

Found in version 30.0.50

Fixed in version 30.1

Done: Mauro Aranda <maurooaranda <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Mauro Aranda <maurooaranda <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 65089 <at> debbugs.gnu.org,
 Augusto Stoffel <arstoffel <at> gmail.com>
Subject: Re: bug#65089: 30.0.50; shell-command filename completion unexpected
 behavior change
Date: Sat, 2 Sep 2023 13:07:45 -0700
Mauro Aranda <maurooaranda <at> gmail.com> writes:

> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
>  >>> Now, with emacs -Q:
>  >>> M-!
>  >>> ls ~/bug/bar
>  >>> Put point between "/" and "b" of "bar" and type TAB
>  >>> emacs says "No match", but I expected it to offer completions,
> foo-1 and
>  >>> foo-2.
>  >>>
>  >>> That was the behavior, at least in Emacs 28. Reverting the following
>  >>> commit, returns this behavior for me:
>  >
>  > The patch below adds yet another heuristic to try and handle the
>  > current case, but really we should rework the pcomplete API so as to
>  > provide us the right info to start with.
>
> I see.  Thanks for your explanation.  In the meantime, I confirm that
> your patch fixes this use case.

Was this installed?  I only see that the bug was left open.




This bug report was last modified 1 year and 287 days ago.

Previous Next


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