GNU bug report logs - #62355
30.0.50; C-g doesn't always quit minibuffer on first press

Previous Next

To reply to this bug, email your comments to 62355 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Toon claes <toon <at> to1.studio>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; C-g doesn't always quit minibuffer on first press
Date: Tue, 21 Mar 2023 20:16:17 +0100

--text follows this line--
Hi,

For a while I've been having trouble C-g isn't quitting the minibuffer
after the first press.

When I start Emacs freshly I can press M-x, that triggers the
minibuffer, and pressing C-g quits the minibuffer again.

But after a short while of use this behaviour changes. Pressing M-x
still triggers the minibuffer, but pressing C-g prints "[Quit]" while it
keeps the minibuffer active. Only after pressing C-g a second time the
minibuffer is actually quit.

I was able to reproduce in "emacs -Q", but I haven't so far been able to
reproduce with "emacs -Q -nw", although I'm not sure it's related to any
of that.

Below is the output of "C-h l" (view-lossage) reproducing the issue:

 C-x b	 ;; switch-to-buffer
 C-g	 ;; abort-minibuffers
 M-x	 ;; execute-extended-command
 C-g C-g ;; abort-minibuffers
 C-h l	 ;; view-lossage

You can see the first time I press C-g once to abort-minibuffers. The
second time I have to C-g twice.

This time it happened right after a fresh start of "emacs -Q", but
sometimes I have to do a lot more actions before the double C-g is
needed.

--
Toon



In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.36, cairo version 1.17.6) of 2023-02-13 built on kumatsu
Repository revision: 609319da870eac75cf4715de8abfaac9233d98f9
Repository branch: master
System Description: Fedora Linux 37 (Workstation Edition)

Configured using:
 'configure --prefix=/home/toon/.local --with-mailutils --with-sound=yes
 --with-pdumper=yes --with-jpeg --with-xpm=ifavailable --with-tiff
 --with-gif --with-png --with-rsvg --with-cairo --with-xml2
 --without-imagemagick --with-native-image-api --with-json --with-xft
 --with-harfbuzz --with-libotf --with-zlib --with-x
 --with-gnutls=ifavailable --with-native-compilation --with-pgtk
 --with-sqlite3 --with-tree-sitter 'CFLAGS=-O0 -g3''

Configured features:
CAIRO DBUS FREETYPE GLIB GSETTINGS HARFBUZZ JPEG JSON LIBOTF LIBSELINUX
LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP
SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3
ZLIB

Important settings:
  value of $LC_MONETARY: en_DK.UTF-8
  value of $LC_NUMERIC: en_DK.UTF-8
  value of $LC_TIME: en_DK.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Messages

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils thingatpt
cl-loaddefs comp comp-cstr warnings icons subr-x rx cl-seq cl-macs gv
cl-extra help-mode bytecomp byte-compile cl-lib display-line-numbers rmc
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win
term/common-win pgtk-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify dynamic-setting system-font-setting
font-render-setting cairo gtk pgtk multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 78372 10344)
 (symbols 48 7192 0)
 (strings 32 19692 1605)
 (string-bytes 1 602285)
 (vectors 16 15469)
 (vector-slots 8 321515 16235)
 (floats 8 29 48)
 (intervals 56 303 0)
 (buffers 984 13))

Message #8 received at 62355 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Toon claes <toon <at> to1.studio>
Cc: 62355 <at> debbugs.gnu.org
Subject: Re: bug#62355: 30.0.50;
 C-g doesn't always quit minibuffer on first press
Date: Wed, 22 Mar 2023 05:29:46 +0200

> Date: Tue, 21 Mar 2023 20:16:17 +0100
> From: Toon claes <toon <at> to1.studio>
> 
> For a while I've been having trouble C-g isn't quitting the minibuffer
> after the first press.
> 
> When I start Emacs freshly I can press M-x, that triggers the
> minibuffer, and pressing C-g quits the minibuffer again.
> 
> But after a short while of use this behaviour changes. Pressing M-x
> still triggers the minibuffer, but pressing C-g prints "[Quit]" while it
> keeps the minibuffer active. Only after pressing C-g a second time the
> minibuffer is actually quit.
> 
> I was able to reproduce in "emacs -Q", but I haven't so far been able to
> reproduce with "emacs -Q -nw", although I'm not sure it's related to any
> of that.
> 
> Below is the output of "C-h l" (view-lossage) reproducing the issue:
> 
>  C-x b	 ;; switch-to-buffer
>  C-g	 ;; abort-minibuffers
>  M-x	 ;; execute-extended-command
>  C-g C-g ;; abort-minibuffers
>  C-h l	 ;; view-lossage
> 
> You can see the first time I press C-g once to abort-minibuffers. The
> second time I have to C-g twice.
> 
> This time it happened right after a fresh start of "emacs -Q", but
> sometimes I have to do a lot more actions before the double C-g is
> needed.

This is normal when you have switched away of the active minibuffer
with "C-x o" or something similar.  The "[Quit]" message (in brackets)
is a telltale sign that the minibuffer is active and waiting for you
to finish some interaction.

However, if you can show a recipe to reproduce this, we could be sure.

Message #11 received at 62355 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>, Toon claes <toon <at> to1.studio>,
 62355 <at> debbugs.gnu.org
Cc: João Távora <joaotavora <at> gmail.com>
Subject: Re: bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first
 press
Date: Thu, 23 Mar 2023 12:31:29 -0700

Hello,

I've been seeing something similar and I have a theory as to the cause.
I am using Icomplete, and I think what happens is that the C-g
interrupts something Icomplete is doing, rather than serving to exit the
minibuffer.  Toon, are you using Icomplete or similar?

Here is my evidence.  One machine on which I use Emacs is underpowered.
With icomplete-show-matches-on-no-input non-nil, on that machine, I type
M-x, and wait for the completions to appear.  I do this several times so
that I have an intuitive sense for how long they take to appear.  And
then I type M-x, and try to hit C-g while Icomplete is computing.  I can
reliably trigger the bug.  If I instead wait two or three seconds after
typing M-x, it never occurs.

-- 
Sean Whitton

Message #14 received at 62355 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>, Eli Zaretskii <eliz <at> gnu.org>,
 Toon claes <toon <at> to1.studio>,
 "62355 <at> debbugs.gnu.org" <62355 <at> debbugs.gnu.org>
Cc: João Távora <joaotavora <at> gmail.com>
Subject: RE: [External] : bug#62355: 30.0.50; C-g doesn't always quit
 minibuffer on first press
Date: Thu, 23 Mar 2023 19:47:49 +0000

Whether or not there's a bug here I leave up
to you.  (But I concur with what Eli said.)
___

While you're using the minibuffer, you
(interactively), as well as code running during
the interaction, can do any number of things,
some of which can initiate contexts where `C-g'
does something specific (e.g. exits from some
interaction within that context).  This is of
course amplified if you (or some code) initiates
a recursive minibuffer.

Things to remember here:

1. `C-g' is a general command.  Its behavior
is specific to the latest context for which it
has a meaning/behavior.

2. To exit the minibuffer (a single level)
directly, you can always use `C-]', which runs
the command `abort-recursive-edit'.

Get in the habit of using `C-j' to cancel/abort
the current minibuffer level.

If you have non-nil `enable-recursive-edit'
then you can also do this when in the minibuffer,
to exit _all_ minibuffer levels and return to
top level: `M-x top-level'.  (It also exits all
recursive edits, not just recursive minibuffers.)

Message #17 received at 62355 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: toon <at> to1.studio, joaotavora <at> gmail.com, 62355 <at> debbugs.gnu.org
Subject: Re: bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first
 press
Date: Thu, 23 Mar 2023 22:09:00 +0200

> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: João Távora <joaotavora <at> gmail.com>
> Date: Thu, 23 Mar 2023 12:31:29 -0700
> 
> I've been seeing something similar and I have a theory as to the cause.
> I am using Icomplete, and I think what happens is that the C-g
> interrupts something Icomplete is doing, rather than serving to exit the
> minibuffer.  Toon, are you using Icomplete or similar?
> 
> Here is my evidence.  One machine on which I use Emacs is underpowered.
> With icomplete-show-matches-on-no-input non-nil, on that machine, I type
> M-x, and wait for the completions to appear.  I do this several times so
> that I have an intuitive sense for how long they take to appear.  And
> then I type M-x, and try to hit C-g while Icomplete is computing.  I can
> reliably trigger the bug.

It isn't a bug, but the expected and intentional behavior.

Message #20 received at 62355 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: toon <at> to1.studio, joaotavora <at> gmail.com, 62355 <at> debbugs.gnu.org
Subject: Re: bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first
 press
Date: Thu, 23 Mar 2023 17:01:08 -0700

On Thu, Mar 23, 2023 at 10:09:00PM +0200, Eli Zaretskii wrote:
>
> It isn't a bug, but the expected and intentional behavior.

I thought that the idea with Icomplete &c. was that they would stop what they
are doing in response to any keystrokes, not requiring an explicit quit, in
order to be maximally unobtrusive.

-- 
Sean Whitton

Message #23 received at 62355 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: toon <at> to1.studio, joaotavora <at> gmail.com, 62355 <at> debbugs.gnu.org
Subject: Re: bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first
 press
Date: Fri, 24 Mar 2023 09:12:13 +0300

> Date: Thu, 23 Mar 2023 17:01:08 -0700
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: toon <at> to1.studio, 62355 <at> debbugs.gnu.org, joaotavora <at> gmail.com
> 
> On Thu, Mar 23, 2023 at 10:09:00PM +0200, Eli Zaretskii wrote:
> >
> > It isn't a bug, but the expected and intentional behavior.
> 
> I thought that the idea with Icomplete &c. was that they would stop what they
> are doing in response to any keystrokes, not requiring an explicit quit, in
> order to be maximally unobtrusive.

We may be talking about two different issues.  The original report
doesn't mention Icomplete (AFAIU), 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.  Prior to Emacs 28, the echo-area message would
instead overwrite the minibuffer contents or conceal it for prolonged
periods of time.

You seem to be talking about something else, perhaps related to what
Icomplete does.  But I'm not at all sure what you describe is the same
behavior as the OP described.

Message #26 received at 62355 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Toon Claes <toon <at> to1.studio>
Cc: joaotavora <at> gmail.com, 62355 <at> debbugs.gnu.org, spwhitton <at> spwhitton.name
Subject: Re: bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first
 press
Date: Fri, 24 Mar 2023 14:56:38 +0300

> From: Toon Claes <toon <at> to1.studio>
> Cc: Sean Whitton <spwhitton <at> spwhitton.name>, 62355 <at> debbugs.gnu.org,
>  joaotavora <at> 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).

Message #29 received at 62355 <at> debbugs.gnu.org (full text, mbox):

From: Toon Claes <toon <at> to1.studio>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: joaotavora <at> gmail.com, 62355 <at> debbugs.gnu.org,
 Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: 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 <at> 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

Message #32 received at 62355 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: Eli Zaretskii <eliz <at> gnu.org>, toon <at> to1.studio, 62355 <at> debbugs.gnu.org
Subject: Re: bug#62355: 30.0.50;
 C-g doesn't always quit minibuffer on first press
Date: Fri, 24 Mar 2023 12:39:29 +0000

On Fri, Mar 24, 2023 at 12:01 AM Sean Whitton <spwhitton <at> spwhitton.name> wrote:
>
> On Thu, Mar 23, 2023 at 10:09:00PM +0200, Eli Zaretskii wrote:
> >
> > It isn't a bug, but the expected and intentional behavior.
>
> I thought that the idea with Icomplete &c. was that they would stop what they
> are doing in response to any keystrokes, not requiring an explicit quit, in
> order to be maximally unobtrusive.

As far as I know, the "unobtrusive" part of Icomplete &c is designed
primarily to let you modify the search pattern upon which Icomplete
is acting to show you potential candidates for the thing you ultimately
want to complete to as quickly as possible, so that if I type, say

M-x fido-mode
M-x
f o o

then the search for all commands whose name contains 'f' is interrupted,
and any results discarded,  as soon as I type the 'o', the 'o' is shown
in the minibuffer, and a search starts anew.  This is realized with
while-no-input. If the completion backend is particularly slow in searching
(which is usually not C-x b's case, but other backends are indeed slow), this
helps a lot in seeing what you are typing.

As far as I know, this behavior is _not_ designed to "tweak" the
C-g behaviour to be anything different from what you would get
if you were not using Icomplete or Fido mode.

That said, I don't understand exactly what you want to happen when you
type C-g before the search is complete, what happens instead, and why
do you think you're seeing a bug.

João

Message #35 received at 62355 <at> debbugs.gnu.org (full text, mbox):

From: Toon Claes <toon <at> to1.studio>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: joaotavora <at> gmail.com, 62355 <at> debbugs.gnu.org, spwhitton <at> spwhitton.name
Subject: Re: bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first
 press
Date: Fri, 24 Mar 2023 16:32:28 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

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

This was a very good clue to point me in the direction of the root
cause. It seems the issue is: my keyboard.

I can reproduce easily by typing M-x C-g on my external keyboard, but I
have *not* been able to reproduce with my built-in laptop keyboard. When
I create the issue with my external keyboard, I can even "repair" it by
pressing C-g on my built-in keyboard.

(FYI I use that keyboard on both computers, that's why I've been seeing
the issue on both. It's a keyboard running QMK firmware.)

Now the only question remains: what is the keyboard sending to make
Emacs hiccup? Is there an easy way to make Emacs display this? I've been
testing with `wev`, but I don't see any suspicious keycodes being sent.

Thanks for helping me debug here. Sorry for the noise, thinking the
issue lays in Emacs, but I didn't know how where else to go.

--
Toon

Message #38 received at 62355 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Toon Claes <toon <at> to1.studio>
Cc: joaotavora <at> gmail.com, 62355 <at> debbugs.gnu.org, spwhitton <at> spwhitton.name
Subject: Re: bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first
 press
Date: Fri, 24 Mar 2023 21:32:34 +0300

> From: Toon Claes <toon <at> to1.studio>
> Cc: spwhitton <at> spwhitton.name, 62355 <at> debbugs.gnu.org, joaotavora <at> gmail.com
> Date: Fri, 24 Mar 2023 16:32:28 +0100
> 
> Now the only question remains: what is the keyboard sending to make
> Emacs hiccup? Is there an easy way to make Emacs display this?

I'd start with "C-h l".

Message #41 received at 62355 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: toon <at> to1.studio, joaotavora <at> gmail.com, 62355 <at> debbugs.gnu.org
Subject: Re: bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first
 press
Date: Fri, 24 Mar 2023 12:17:20 -0700

Hello,

On Fri 24 Mar 2023 at 09:12AM +03, Eli Zaretskii wrote:

>> Date: Thu, 23 Mar 2023 17:01:08 -0700
>> From: Sean Whitton <spwhitton <at> spwhitton.name>
>> Cc: toon <at> to1.studio, 62355 <at> debbugs.gnu.org, joaotavora <at> gmail.com
>>
>> On Thu, Mar 23, 2023 at 10:09:00PM +0200, Eli Zaretskii wrote:
>> >
>> > It isn't a bug, but the expected and intentional behavior.
>>
>> I thought that the idea with Icomplete &c. was that they would stop what they
>> are doing in response to any keystrokes, not requiring an explicit quit, in
>> order to be maximally unobtrusive.
>
> We may be talking about two different issues.

My apologies for confusing things.  I'll file a separate bug.

-- 
Sean Whitton

Message #44 received at 62355 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Toon claes <toon <at> to1.studio>
Cc: 62355 <at> debbugs.gnu.org
Subject: Re: bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first
 press
Date: Fri, 24 Mar 2023 17:59:59 -0400

> For a while I've been having trouble C-g isn't quitting the minibuffer
> after the first press.

The issue may reflect a real bug, but maybe not: `C-g` will exit the
minibuffer if Emacs is sitting idle in the minibuffer but it will
interrupt what's currently running if Emacs is not currently idle.

Sometimes this "idleness" is not obvious (it can be some timer code or
something running asynchronously).

Maybe we should tweak the behavior of `while-no-input` (or provide a new
macro for that) so that a `C-g` hit during its execution causes both the
interruption of what was going on *and* the execution of the command
bound to `C-g`?


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.