bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: 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: address@hidden, address@hidden, address@hidden,
>  address@hidden
> From: Dmitry Gutov <address@hidden>
> 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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]