On Thu, Mar 5, 2020 at 1:40 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 05.03.2020 14:30, João Távora wrote:
> >     And when they use that "out", and the program behaves randomly,
> they'll
> >     get annoyed, file confusing bug reports, etc. Why would we want that?
> >
> >
> > Any of those things are better than the feeling of being trapped in a
> > UI.
>
> First: I disagree with that assessment.
>
> 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.

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.


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


> > Well, as I said I do remember binding M-j to it for this specific
> > circumstance, but that's before your fix (which I am still to try out).
>
> Please do when you have the time.
>

Sure.


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

-- 
João Távora