Why does `read-multiple-choice' lock user into minbuffer?

Why does `read-multiple-choice' lock user into minbuffer?

[Karl Fogel]

When I tried to send an email recently, I got prompted by `nsm-query-user' (in lisp/net/nsm.el), as the remote SMTP server I was sending through had rolled over its LetsEncrypt certificate during my Emacs session.

This caused me to get prompted with the expected array of choices:

  (a)lways        -> "Accept this certificate this session and for all future sessions"
  (s)ession only  -> "Accept this certificate this session only"
  (n)o            -> "Refuse to use this certificate, and close the connection"
  etc, etc

And while the minibuffer asked me for a response, a new "*Network Security Manager*" buffer was helpfully displayed in a new window.

I wanted to copy some text from that buffer, so I tried `C-x o' to get over there.  But that didn't work: point was locked into the minibuffer.  I tried clicking with my mouse in the other window, but that did not bring me to the window either.  And since `nsm-query-user' kills the "*Network Security Manager*" buffer after the user gives her answer, in the end I had no way to copy that text.  I couldn't do it while the buffer was being shown to me, and I also couldn't do it after I'd finished responding to `read-multiple-choice' -- because by the time control got back to me, the buffer I wanted no longer existed.

Now, a local solution to this problem would be to just not kill the buffer at the end of `nsm-query-user'.  (Actually, there are two buffers killed there, and I don't really see why we should kill either of them at the end -- `nsm-query-user' erases them when it needs to.)

But I'd like to understand the more general question too: why does `read-multiple-choice' lock the user into the minbuffer so strictly?

Its doc string doesn't say anything about this behavior, and other functions that prompt the user (e.g., `find-file') don't enforce minibuffer habitation the same way.

Best regards,
-Karl

Re: Why does `read-multiple-choice' lock user into minbuffer?

[Kévin Le Gouguec]

Karl Fogel <kfogel@red-bean.com> writes:

> But I'd like to understand the more general question too: why does
> `read-multiple-choice' lock the user into the minbuffer so strictly?

IIUC (but maybe I'm wrong; I'm not entirely sure I understand all the
nuances between the minibuffer and the echo-area), it's "just" an
implementation detail: read-multiple-choice uses read-event, which does
not use the minibuffer.

So you're not actually "locked into the minibuffer" (if you were, keys
such as C-x o would be available to you), it's just that
read-multiple-choice traps you in a while-loop, calling read-event until
you hit one of the keys you are prompted for.

FWIW, back in December[1] Juri mentioned that read-multiple-choice
should probably be patched to use the minibuffer.


[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35564#184

Re: Why does `read-multiple-choice' lock user into minbuffer?

[Kévin Le Gouguec]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> FWIW, back in December[1] Juri mentioned that read-multiple-choice

s/December/November/

Re: Why does `read-multiple-choice' lock user into minbuffer?

[Juri Linkov]

>> But I'd like to understand the more general question too: why does
>> `read-multiple-choice' lock the user into the minbuffer so strictly?
>
> IIUC (but maybe I'm wrong; I'm not entirely sure I understand all the
> nuances between the minibuffer and the echo-area), it's "just" an
> implementation detail: read-multiple-choice uses read-event, which does
> not use the minibuffer.
>
> So you're not actually "locked into the minibuffer" (if you were, keys
> such as C-x o would be available to you), it's just that
> read-multiple-choice traps you in a while-loop, calling read-event until
> you hit one of the keys you are prompted for.
>
> FWIW, back in December[1] Juri mentioned that read-multiple-choice
> should probably be patched to use the minibuffer.
>
> [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35564#184

Indeed, read-multiple-choice should use the minibuffer.
Other similar functions were already patched to use
the minibuffer.

Re: Why does `read-multiple-choice' lock user into minbuffer?

[Lars Ingebrigtsen]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> FWIW, back in December[1] Juri mentioned that read-multiple-choice
> should probably be patched to use the minibuffer.

Yup, I agree.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Why does `read-multiple-choice' lock user into minbuffer?

[T.V Raman]

Lars Ingebrigtsen <larsi@gnus.org> writes:

The other function that demonstrates the same issue is read-char-choice
and clients that use it --e.g. magit et al then are forced to put up
hard to parse prompts of the form [u]rl, [n]ame, ... as an
example. Another good example of a hard to use client UI is org's export
wizard.

Note: If you can see the screen, prompts like the above work once you're
familiar with them, with spoken output, they're a complete usability disaster.
--
> Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:
>
>> FWIW, back in December[1] Juri mentioned that read-multiple-choice
>> should probably be patched to use the minibuffer.
>
> Yup, I agree.

-- 

Re: Why does `read-multiple-choice' lock user into minbuffer?

[Karl Fogel]

On 26 Jun 2020, T.V Raman wrote:
>Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>The other function that demonstrates the same issue is read-char-choice
>and clients that use it --e.g. magit et al then are forced to put up
>hard to parse prompts of the form [u]rl, [n]ame, ... as an
>example. Another good example of a hard to use client UI is org's export
>wizard.
>
>Note: If you can see the screen, prompts like the above work once you're
>familiar with them, with spoken output, they're a complete usability disaster.
>--
>> Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:
>>
>>> FWIW, back in December[1] Juri mentioned that read-multiple-choice
>>> should probably be patched to use the minibuffer.
>>
>> Yup, I agree.

Thanks, everyone.  I will try to find time to do something on this this weekend.  I'll post a patch in this thread for review before committing anything, as (I suspect) this is an unfamiliar area of the code for me.

Best regards,
-Karl