[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why does `read-multiple-choice' lock user into minbuffer?
From: |
Kévin Le Gouguec |
Subject: |
Re: Why does `read-multiple-choice' lock user into minbuffer? |
Date: |
Fri, 19 Jun 2020 09:43:01 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
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