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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 38992 <at> debbugs.gnu.org, joaotavora <at> gmail.com, waah <at> yellowfrog.io,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#38992: 27.0.60; when enabled, fido-mode seems to break
 vc-git-grep
Date: Wed, 05 Feb 2020 16:20:47 +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: Wed, 5 Feb 2020 02:57:18 +0300
> 
> On 01.02.2020 11:07, Eli Zaretskii wrote:
> > The second one is fine with me, but why do we need the first one?  It
> > changes the semantics of a widely used variable.
> 
> The short of it, the second wouldn't work without the first one.

Pity.

> And the first one makes a lot of sense (no need to invent an extra
> variable if the way to store the necessary info is so obvious).

I didn't say it didn't make sense.  The only issue that worries me is
how safe it is for the release branch.  I have no issues whatsoever
with making these changes on master.

> There is some possibility of this causing a regression, but the changes 
> are relatively small. And no third-party code should be affected by this 
> change.

Are you sure about third-party code?  I'm worried by exactly the same
assumptions as those which required you to do, e.g., the likes of
this:

  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.

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.

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?

Previous Next

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