unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Toon Claes <toon@to1.studio>
Cc: joaotavora@gmail.com, 62355@debbugs.gnu.org, spwhitton@spwhitton.name
Subject: bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first press
Date: Fri, 24 Mar 2023 14:56:38 +0300	[thread overview]
Message-ID: <835yaqe51l.fsf@gnu.org> (raw)
In-Reply-To: <87edpe7eiw.fsf@to1.studio> (message from Toon Claes on Fri, 24 Mar 2023 08:56:39 +0100)

> From: Toon Claes <toon@to1.studio>
> Cc: Sean Whitton <spwhitton@spwhitton.name>, 62355@debbugs.gnu.org,
>  joaotavora@gmail.com
> Date: Fri, 24 Mar 2023 08:56:39 +0100
> 
> 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.

Yes.

> 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.

The "[Quit]" part, and the fact that you need to type C-g twice _is_
the intended behavior -- in the situation that I described earlier,
i.e. if the minibuffer was activated by another command.

What might not be intentional is how you get to that situation.  Since
you haven't shown any reproducible recipe to recreate that situation,
I don't know what it is and how you get to it.  Just typing random
sequences of M-x and C-g doesn't recreate it here.

> 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.

The "[Quit]" behavior is correct, so looking for it will not help.
You need to show the sequence of commands you type to get to this
state, then we will be making some progress.

> * It feels like it's timing related. It starts happening from a random
> number of actions.

Show what "C-h l" tells you about the sequence.  Enlarge the size of
the recent-keys array if you have to, to let it record more.

> * I cannot reproduce in "emacs -Q -nw", I'm not sure what to conclude
> from that.

We will know when we understand why it does happen in GUI sessions.
But in general, C-g in a -nw session generates SIGINT, and so is
processed differently than C-g in a GUI session.

> 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?

There's no need for that, I believe you even without the screen
recording.  And I see this behavior myself from time to time (except
that in my case it happens when it should and when I expect it to
happen).





  reply	other threads:[~2023-03-24 11:56 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-21 19:16 bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first press Toon claes
2023-03-22  3:29 ` Eli Zaretskii
2023-03-23 19:31   ` Sean Whitton
2023-03-23 19:47     ` Drew Adams
2023-03-23 20:09     ` Eli Zaretskii
2023-03-24  0:01       ` Sean Whitton
2023-03-24  6:12         ` Eli Zaretskii
2023-03-24  7:56           ` Toon Claes
2023-03-24 11:56             ` Eli Zaretskii [this message]
2023-03-24 15:32               ` Toon Claes
2023-03-24 18:32                 ` Eli Zaretskii
2023-03-24 19:17           ` Sean Whitton
2023-03-24 12:39         ` João Távora
2023-03-26 20:44           ` bug#62468: 30.0.50; Improve Icomplete while-no-input s.t. C-g quits the minibuffer Sean Whitton
2023-03-24 21:59 ` bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first press Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=835yaqe51l.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=62355@debbugs.gnu.org \
    --cc=joaotavora@gmail.com \
    --cc=spwhitton@spwhitton.name \
    --cc=toon@to1.studio \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).