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

["João Távora" <joaotavora@gmail.com>]

After a few days of successful testing, I've taken the liberty of pushing
Dmitry's fixes to emacs-27.

Dmitry's fix is fully backward-compatible (doesn't remove any variables or
change their meanings), and merely fixes a pre-existing bug in
lisp/minibuffer.el by introducing a new internal, user-invisible variable,
which we can later remove/rework in master.

I'm also marking this bug done (not sure if it wasn't already),
João


On Thu, Mar 5, 2020 at 6:09 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > 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?



-- 
João Távora