unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).