* Why does `read-multiple-choice' lock user into minbuffer?
@ 2020-06-19 4:47 Karl Fogel
2020-06-19 7:43 ` Kévin Le Gouguec
0 siblings, 1 reply; 7+ messages in thread
From: Karl Fogel @ 2020-06-19 4:47 UTC (permalink / raw)
To: Emacs Development
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Why does `read-multiple-choice' lock user into minbuffer?
2020-06-19 4:47 Why does `read-multiple-choice' lock user into minbuffer? Karl Fogel
@ 2020-06-19 7:43 ` Kévin Le Gouguec
2020-06-19 7:44 ` Kévin Le Gouguec
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Kévin Le Gouguec @ 2020-06-19 7:43 UTC (permalink / raw)
To: Karl Fogel; +Cc: Emacs Development
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Why does `read-multiple-choice' lock user into minbuffer?
2020-06-19 7:43 ` Kévin Le Gouguec
@ 2020-06-19 7:44 ` Kévin Le Gouguec
2020-06-21 22:37 ` Juri Linkov
2020-06-26 9:08 ` Lars Ingebrigtsen
2 siblings, 0 replies; 7+ messages in thread
From: Kévin Le Gouguec @ 2020-06-19 7:44 UTC (permalink / raw)
To: Karl Fogel; +Cc: Emacs Development
Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:
> FWIW, back in December[1] Juri mentioned that read-multiple-choice
s/December/November/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Why does `read-multiple-choice' lock user into minbuffer?
2020-06-19 7:43 ` Kévin Le Gouguec
2020-06-19 7:44 ` Kévin Le Gouguec
@ 2020-06-21 22:37 ` Juri Linkov
2020-06-26 9:08 ` Lars Ingebrigtsen
2 siblings, 0 replies; 7+ messages in thread
From: Juri Linkov @ 2020-06-21 22:37 UTC (permalink / raw)
To: Kévin Le Gouguec; +Cc: Karl Fogel, Emacs Development
>> 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Why does `read-multiple-choice' lock user into minbuffer?
2020-06-19 7:43 ` Kévin Le Gouguec
2020-06-19 7:44 ` Kévin Le Gouguec
2020-06-21 22:37 ` Juri Linkov
@ 2020-06-26 9:08 ` Lars Ingebrigtsen
2020-06-26 14:35 ` T.V Raman
2 siblings, 1 reply; 7+ messages in thread
From: Lars Ingebrigtsen @ 2020-06-26 9:08 UTC (permalink / raw)
To: Kévin Le Gouguec; +Cc: Karl Fogel, Emacs Development
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Why does `read-multiple-choice' lock user into minbuffer?
2020-06-26 9:08 ` Lars Ingebrigtsen
@ 2020-06-26 14:35 ` T.V Raman
2020-06-26 17:57 ` Karl Fogel
0 siblings, 1 reply; 7+ messages in thread
From: T.V Raman @ 2020-06-26 14:35 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Kévin Le Gouguec, Karl Fogel, Emacs Development
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.
--
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Why does `read-multiple-choice' lock user into minbuffer?
2020-06-26 14:35 ` T.V Raman
@ 2020-06-26 17:57 ` Karl Fogel
0 siblings, 0 replies; 7+ messages in thread
From: Karl Fogel @ 2020-06-26 17:57 UTC (permalink / raw)
To: T.V Raman; +Cc: Lars Ingebrigtsen, Emacs Development, Kévin Le Gouguec
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-06-26 17:57 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-06-19 4:47 Why does `read-multiple-choice' lock user into minbuffer? Karl Fogel
2020-06-19 7:43 ` Kévin Le Gouguec
2020-06-19 7:44 ` Kévin Le Gouguec
2020-06-21 22:37 ` Juri Linkov
2020-06-26 9:08 ` Lars Ingebrigtsen
2020-06-26 14:35 ` T.V Raman
2020-06-26 17:57 ` Karl Fogel
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.