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

From: Eli Zaretskii <[email-masked]>
Date: Wed, 05 Feb 2020 16:20:47 +0200

> Cc: [email-masked], [email-masked], [email-masked],
>  [email-masked]
> From: Dmitry Gutov <[email-masked]>
> 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?