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

[Dmitry Gutov]

On 05.03.2020 15:54, João Távora wrote:

>     Second: trapped by the UI or not, we are still limited by what values
>     the program that called completing-read is prepared to handle.
>
>
> Of course.  What I'm saying it that there may be completing-read
> that may benefit from an informed exit with something not in the
> completion list. Calculating a completion list is fickle and often
> it fails by scarceness.

OK, fair enough.

>     I mean... if your idea of an "out" is to give it a "finger-contorting"
>     binding and a secret password, of course that's unlikely to cause many
>     problems.
>
>
> Yep, that's my idea. Or a C-u to your icomplete-fido-exit would do just 
> fine,
> too.  Assume "secret password" is you being funny.

How about 'M-x exit-minibuffer RET'? :-) If it's indeed a rare situation.

>     I don't know how (or why) to add instructions to the docstring for
>     something that we advise against doing, though. What phrasing to
>     use, etc.
>
>
> Well, I don't advise against it, you do. I just want to give users
> a better library. But if you're fine with C-u.

I will recuse myself by saying I have no opinion on C-u.

>     And also, here's a thought: anytime you feel like using
>     'exit-minibuffer' to counter the REQUIRE-MATCH=t argument, that should
>     probably be accompanied by a patch to the caller function to change
>     that
>     argument to nil.
>
>
> Sure, time-permitting, of course.  But again, not that the changing of
> the argument might _not_ be the fix.  I expect the real fix in those
> situations to be about the computation of the allowed completions.
> Those are probably more complex fixes.

That makes sense, but in general, when the caller fails to enumerate all 
possibilities, it should set require-match to nil. But it's not so 
black-or-white, OK.