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

[Eli Zaretskii]

> Cc: 38992@debbugs.gnu.org, joaotavora@gmail.com, monnier@iro.umontreal.ca,
>  waah@yellowfrog.io
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 5 Mar 2020 02:15:21 +0200
> 
> >    diff --git a/lisp/icomplete.el b/lisp/icomplete.el
> >    index a1a67e2330..52429fdf37 100644
> >    --- a/lisp/icomplete.el
> >    +++ b/lisp/icomplete.el
> >    @@ -541,7 +541,7 @@ icomplete-exhibit
> >                          (icomplete--completion-table)
> >                          (icomplete--completion-predicate)
> >                          (if (window-minibuffer-p)
> >    -                              (not minibuffer-completion-confirm)))))
> >    +                              (eq minibuffer-completion-confirm t)))))
> >                 (buffer-undo-list t)
> >                 deactivate-mark)
> >            ;; Do nothing if while-no-input was aborted.
> 
> The above is a simple bugfix of "why the hell not" variety: I don't 
> think that code worked well before that patch, i.e. it treated the 
> values of nil and t of REQUIRE-MATCH the same. Good thing that only 
> affected the choice of parens to print in the minibuffer.
> 
> > IOW, some code which just assumes that anything non-nil and
> > non-confirm must be confirm-after-completion, or the other way
> > around.  It's an incompatible change.
> 
> I'm not arguing that is isn't. But looking at the actual uses out there, 
> the chief popular alternatives to completing-read-default don't seem to 
> be affected. And this variable is bound inside completing-read-default, 
> so only particular kind of code could really use it. Breakage is 
> possible, of course, but I'm fairly sure the affected audience would be 
> minimal.
> 
> Anyway, see the alternative patches in the branch 'fido-mode-fix' I just 
> pushed.
> 
> > Is the problem this attempts to fix really serious?  Or is it just a
> > minor inconvenience?  It isn't the original one that started the bug
> > report, right?
> 
> The patches fix both an inconvenience (one that started this bug report, 
> I'd say it is serious enough to make users stumped) and a bug. See my 
> previous message in this bug report for details.

Thanks for the explanations.

Stefan, any thoughts on whether this is safe for emacs-27?