[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first press
From: |
Toon Claes |
Subject: |
bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first press |
Date: |
Fri, 24 Mar 2023 08:56:39 +0100 |
Eli Zaretskii <eliz@gnu.org> writes:
> We may be talking about two different issues. The original report
> doesn't mention Icomplete (AFAIU)
I'm not using icomplete. I can reproduce with "emacs -Q", so it
shouldn't be related to any (non-default) package.
> , it mentions the fact that C-g,
> instead of exiting the minibuffer, just displays "[Quit]" (note the
> brackets). That is the expected and intentional behavior in Emacs 28
> and later when Emacs needs to display an echo-area message and the
> minibuffer is active.
Let me try to understand correctly what you mean by "intentional
behavior".
When I type "emacs -Q" <ENTER>, press "M-x" the minibuffer opens, I do
nothing else, I just type "C-g" to abort. Then I see "Quit" (no
brackets) in the echo area and the cursor is sent back to the original
buffer. This works as intended IMHO.
Now, the issue I'm having, I can repeat pressing alternating "M-x" "C-g"
a few times, and at some point the minibuffer shows "[Quit]" (with
brackets) and the minibuffer remains active. From this point my Emacs is
"tainted" and *every* action in the minibuffer requires "C-g" twice to
exit. In my opinion this is not intended behavior.
So some of my theories:
* Some internal state gets stuck. If you can give me some guidance on
where in the source code this behavior to display "[Quit]" comes from,
I'm happy to attach gdb to dig a bit deeper.
* It feels like it's timing related. It starts happening from a random
number of actions.
* I cannot reproduce in "emacs -Q -nw", I'm not sure what to conclude
from that.
I can reproduce on two computers I have, one is running Fedora, other is
running Arch. On both I'm using Sway on Wayland and Emacs with PGTK.
I know it's a weird issue, and I'm willing to help debug. I can make a
screen recording if you want to see it in action?
--
Toon
- bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first press, Toon claes, 2023/03/21
- bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first press, Eli Zaretskii, 2023/03/21
- bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first press, Sean Whitton, 2023/03/23
- bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first press, Drew Adams, 2023/03/23
- bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first press, Eli Zaretskii, 2023/03/23
- bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first press, Sean Whitton, 2023/03/23
- bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first press, Eli Zaretskii, 2023/03/24
- bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first press,
Toon Claes <=
- bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first press, Eli Zaretskii, 2023/03/24
- bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first press, Toon Claes, 2023/03/24
- bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first press, Eli Zaretskii, 2023/03/24
- bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first press, Sean Whitton, 2023/03/24
- bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first press, João Távora, 2023/03/24
- bug#62468: 30.0.50; Improve Icomplete while-no-input s.t. C-g quits the minibuffer, Sean Whitton, 2023/03/26
bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first press, Stefan Monnier, 2023/03/24