bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command


From: Eli Zaretskii
Subject: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Wed, 05 May 2021 15:06:52 +0300

> Cc: 47969@debbugs.gnu.org, robert@capuchin.co.uk
> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 5 May 2021 09:25:26 +0200
> 
> Basically, it all boils down to whether we want our minibuffer
> interactions be modal or not.  I sometimes start a dialogue and, in
> order to finish it, look into some other buffer and maybe even start
> some recursive dialogue before returning to the prior one.  While doing
> that I probably would like autoselection to behave as usual.  OTOH a
> strictly modal dialogue like `yes-or-no-p' should probably disallow
> autoselection.

The problem here is that Emacs is unable to react reasonably to
autoselection in the middle of reading a key sequence.  So modal or
not, we simply cannot support the kind of excursions that you like to
make until the key sequence being read was read in its entirety.  Note
that this doesn't necessarily mean we exit the minibuffer, so we could
still support non-modal prompts.  But we cannot do that between ESC
and the rest of the sequence, or between C-x and the rest, or in any
other situation when the user pressed one or more prefix keys, because
we have only one channel for reading keys, and we loop there until we
have a complete sequence that maps to some command.

My suggestion was to disable (or delay) mouse autoselection until the
key sequence is completely read, if that's possible.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]