bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#38992: 27.0.60; when enabled, fido-mode seems to break vc-git-grep


From: Stefan Monnier
Subject: bug#38992: 27.0.60; when enabled, fido-mode seems to break vc-git-grep
Date: Fri, 24 Jan 2020 09:11:55 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

>> We could introduce a new `minibuffer-require-match` variable (and mark
>> `minibuffer-completion-confirm` obsolete).
> Why don't we just co-opt the older variable.

It's arguably breaking compatibility.  But you might be right that maybe
it's a non issue.  A quick `grep` shows that outside Emacs itself, at
least Helm might be affected.

> Here's another issue related to the previous proposed fix: why *would* M-j
> exit minibuffer in all cases? It currently doesn't honor REQUIRE-MATCH=t (or
> the confirm- values, but I don't care about that). The default
> completing-read, as well as icomplete-mode, both honor it. The patch
> 2 fixes that.

Sounds like a plain bug fix, yes.

> --- a/lisp/minibuffer.el
> +++ b/lisp/minibuffer.el
> @@ -1386,7 +1386,10 @@ minibuffer-force-complete-and-exit
>     (minibuffer-prompt-end) (point-max) #'exit-minibuffer
>     ;; If the previous completion completed to an element which fails
>     ;; test-completion, then we shouldn't exit, but that should be rare.
> -   (lambda () (minibuffer-message "Incomplete"))))
> +   (lambda ()
> +     (if minibuffer-completion-predicate
> +         (minibuffer-message "Incomplete")
> +       (exit-minibuffer)))))

I think this is a typo for `minibuffer-completion-confirm`, right?


        Stefan






reply via email to

[Prev in Thread] Current Thread [Next in Thread]