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

[Dmitry Gutov]

On 05.02.2020 16:20, Eli Zaretskii wrote:

> > 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.

I wouldn't say it's absolutely safe, but it would make me happier to 
root out logical problems with the existing variable before the release.

> > 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.

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.