GNU bug report logs - #41705
28.0.50; minibuffer completion of ".../*/*" shouldn't be "...//"

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 41705 in the body.
You can then email your comments to 41705 AT debbugs.gnu.org in the normal way.

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

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

From: Pip Cet <pipcet <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; minibuffer completion of ".../*/*" shouldn't be "...//"
Date: Thu, 04 Jun 2020 09:35:12 +0000

Recipe:

./emacs -Q
enter: C-x C-f * / * <tab>

expected result: a list of sub-subdirectories of the emacs src dir. A
"Find file: .../emacs/src/*/" prompt.

actual result: prompt says "Find file: .../emacs/src//", further tab
completion uses the root directory.

I'd noticed this for a while now, but thought it was a local
configuration issue. It happens in emacs -Q, too, though.

For master, we should fix minibuffer.el properly, but I'm not sure what
to do on emacs-27. It's a regression (from Emacs 26) that might annoy
many users of tab completion in the minibuffer.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 41705 <at> debbugs.gnu.org
Subject: Re: bug#41705: 28.0.50;
 minibuffer completion of ".../*/*" shouldn't be "...//"
Date: Thu, 04 Jun 2020 16:36:00 +0300

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Thu, 04 Jun 2020 09:35:12 +0000
> 
> ./emacs -Q
> enter: C-x C-f * / * <tab>
> 
> expected result: a list of sub-subdirectories of the emacs src dir. A
> "Find file: .../emacs/src/*/" prompt.
> 
> actual result: prompt says "Find file: .../emacs/src//", further tab
> completion uses the root directory.
> 
> I'd noticed this for a while now, but thought it was a local
> configuration issue. It happens in emacs -Q, too, though.
> 
> For master, we should fix minibuffer.el properly, but I'm not sure what
> to do on emacs-27. It's a regression (from Emacs 26) that might annoy
> many users of tab completion in the minibuffer.

Can you bisect to find which commit broke this?

Thanks.

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

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 41705 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Pip Cet <pipcet <at> gmail.com>
Subject: Re: bug#41705: 28.0.50; minibuffer completion of ".../*/*"
 shouldn't be "...//"
Date: Thu, 04 Jun 2020 15:18:31 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Pip Cet <pipcet <at> gmail.com>
>> Date: Thu, 04 Jun 2020 09:35:12 +0000
>> 
>> ./emacs -Q
>> enter: C-x C-f * / * <tab>
>> 
>> expected result: a list of sub-subdirectories of the emacs src dir. A
>> "Find file: .../emacs/src/*/" prompt.
>> 
>> actual result: prompt says "Find file: .../emacs/src//", further tab
>> completion uses the root directory.
>> 
>> I'd noticed this for a while now, but thought it was a local
>> configuration issue. It happens in emacs -Q, too, though.
>> 
>> For master, we should fix minibuffer.el properly, but I'm not sure what
>> to do on emacs-27. It's a regression (from Emacs 26) that might annoy
>> many users of tab completion in the minibuffer.
>
> Can you bisect to find which commit broke this?

I selectively applied commits onto emacs-26 rather than bisecting, and
it seems to point to [1].  Paging Stefan.

[1]: * lisp/minibuffer.el (completion-pcm--optimize-pattern): New function
8bea7e9ab4 2019-12-03 09:45:48 -0500
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=8bea7e9ab4453da71d9766d582089154f31de907

-- 
Basil

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

From: Pip Cet <pipcet <at> gmail.com>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 41705 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#41705: 28.0.50; minibuffer completion of ".../*/*"
 shouldn't be "...//"
Date: Thu, 04 Jun 2020 18:26:37 +0000

[Message part 1 (text/plain, inline)]

"Basil L. Contovounesios" <contovob <at> tcd.ie> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>>> From: Pip Cet <pipcet <at> gmail.com>
>>> Date: Thu, 04 Jun 2020 09:35:12 +0000
>>> 
>>> ./emacs -Q
>>> enter: C-x C-f * / * <tab>
>>> 
>>> expected result: a list of sub-subdirectories of the emacs src dir. A
>>> "Find file: .../emacs/src/*/" prompt.
>>> 
>>> actual result: prompt says "Find file: .../emacs/src//", further tab
>>> completion uses the root directory.
>>> 
>>> I'd noticed this for a while now, but thought it was a local
>>> configuration issue. It happens in emacs -Q, too, though.
>>> 
>>> For master, we should fix minibuffer.el properly, but I'm not sure what
>>> to do on emacs-27. It's a regression (from Emacs 26) that might annoy
>>> many users of tab completion in the minibuffer.
>>
>> Can you bisect to find which commit broke this?
>
> I selectively applied commits onto emacs-26 rather than bisecting, and
> it seems to point to [1].  Paging Stefan.

Thanks for that!

I'd actually suspected the same file as well, and started playing around
with the code a little. I'm suspicious of the code in
completion-pcm--optimize-pattern which turns a '(star) pattern into
nil. That's correct as far as which strings qualify as matches, but it's
incorrect because it doesn't survive the completion-pcm--pattern->string
round trip.

I think we get something closer to Emacs-26 behavior back with this
patch.

[0001-Don-t-optimize-away-star-patterns-in-minibuffer-file.patch (text/x-diff, inline)]

From b21734a42860b153a381ac92e5c17f863da4c8da Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet <at> gmail.com>
Date: Thu, 4 Jun 2020 18:21:42 +0000
Subject: [PATCH] Don't optimize away star patterns in minibuffer file name
 completion

* lisp/minibuffer.el (completion-pcm--optimize-pattern): Keep
'star in the pattern.  (Bug#41705)
---
 lisp/minibuffer.el | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index d2c3f9045e..15deccc1c3 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -3112,12 +3112,12 @@ completion-pcm--optimize-pattern
     (while p
       (pcase p
         (`(,(or 'any 'any-delim) point . ,rest) (setq p `(point . ,rest)))
-        ;; This is not just a performance improvement: it also turns
-        ;; a terminating `point' into an implicit `any', which
-        ;; affects the final position of point (because `point' gets
-        ;; turned into a non-greedy ".*?" regexp whereas we need
-        ;; it the be greedy when it's at the end, see bug#38458).
-        (`(,(pred symbolp)) (setq p nil)) ;Implicit terminating `any'.
+        ;; This is not just a performance improvement: it turns a
+        ;; terminating `point' into an implicit `any', which affects
+        ;; the final position of point (because `point' gets turned
+        ;; into a non-greedy ".*?" regexp whereas we need it to be
+        ;; greedy when it's at the end, see bug#38458).
+        (`(point) (setq p nil)) ;Implicit terminating `any'.
         (_ (push (pop p) n))))
     (nreverse n)))
 
-- 
2.27.0.rc0

[Message part 3 (text/plain, inline)]

But it's fairly obvious this code is both tricky and should be worked on
some more, which probably precludes inclusion in emacs-27 (without
further testing) and master, respectively.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, Eli Zaretskii <eliz <at> gnu.org>,
 41705 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#41705: 28.0.50; minibuffer completion of ".../*/*"
 shouldn't be "...//"
Date: Fri, 14 Aug 2020 19:18:01 +0200

Pip Cet <pipcet <at> gmail.com> writes:

>> I selectively applied commits onto emacs-26 rather than bisecting, and
>> it seems to point to [1].  Paging Stefan.
>
> Thanks for that!
>
> I'd actually suspected the same file as well, and started playing around
> with the code a little. I'm suspicious of the code in
> completion-pcm--optimize-pattern which turns a '(star) pattern into
> nil. That's correct as far as which strings qualify as matches, but it's
> incorrect because it doesn't survive the completion-pcm--pattern->string
> round trip.
>
> I think we get something closer to Emacs-26 behavior back with this
> patch.

This was a couple of months ago, but was apparently never applied?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Pip Cet <pipcet <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, Eli Zaretskii <eliz <at> gnu.org>,
 41705 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#41705: 28.0.50; minibuffer completion of ".../*/*" shouldn't
 be "...//"
Date: Fri, 14 Aug 2020 17:48:02 +0000

On Fri, Aug 14, 2020 at 5:18 PM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> Pip Cet <pipcet <at> gmail.com> writes:
> > I think we get something closer to Emacs-26 behavior back with this
> > patch.
>
> This was a couple of months ago, but was apparently never applied?

I was hoping Stefan would chime in.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, Eli Zaretskii <eliz <at> gnu.org>,
 41705 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#41705: 28.0.50; minibuffer completion of ".../*/*"
 shouldn't be "...//"
Date: Thu, 01 Oct 2020 05:07:58 +0200

Pip Cet <pipcet <at> gmail.com> writes:

>> > I think we get something closer to Emacs-26 behavior back with this
>> > patch.
>>
>> This was a couple of months ago, but was apparently never applied?
>
> I was hoping Stefan would chime in.

I can't hear any chimes, and your patch fixes the bug, so I went ahead
and applied it to Emacs 28.  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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