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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 38992 <at> debbugs.gnu.org, joaotavora <at> gmail.com, waah <at> yellowfrog.io
Subject: Re: bug#38992: 27.0.60; when enabled, fido-mode seems to break
 vc-git-grep
Date: Thu, 05 Mar 2020 08:08:42 +0200

> Cc: 38992 <at> debbugs.gnu.org, joaotavora <at> gmail.com, monnier <at> iro.umontreal.ca,
>  waah <at> yellowfrog.io
> From: Dmitry Gutov <dgutov <at> 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?

Previous Next

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