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

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

[Toon claes]

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

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

[Eli Zaretskii]

> Date: Tue, 21 Mar 2023 20:16:17 +0100
> From: Toon claes <toon@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.

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

[Sean Whitton]

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

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

[Drew Adams]

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

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

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: João Távora <joaotavora@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.

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

[Sean Whitton]

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

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

[Eli Zaretskii]

> Date: Thu, 23 Mar 2023 17:01:08 -0700
> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: toon@to1.studio, 62355@debbugs.gnu.org, joaotavora@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.

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

[Toon Claes]

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

[Eli Zaretskii]

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

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

[Toon Claes]

Eli Zaretskii <eliz@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

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

[Eli Zaretskii]

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

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

[Sean Whitton]

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@spwhitton.name>
>> Cc: toon@to1.studio, 62355@debbugs.gnu.org, joaotavora@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

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

[João Távora]

On Fri, Mar 24, 2023 at 12:01 AM Sean Whitton <spwhitton@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

bug#62468: 30.0.50; Improve Icomplete while-no-input s.t. C-g quits the minibuffer

[Sean Whitton]

Hello,

X-debbugs-cc: joaotavora@gmail.com

On Fri 24 Mar 2023 at 12:39PM GMT, João Távora wrote:

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

Thank you for this summary.  So, this is pretty much a feature request
to extend the unobtrusiveness a bit further, if we can.

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

Okay, how about this.  As you describe, typing any self-insert chars
while Icomplete is computing what to display cancels and restarts that
computation.  The primary purpose of this, as you say, is to allow the
user to modify the search pattern as quickly as possible.

A slightly broader way to understand the same thing is as allowing the
user to /ignore Icomplete until they've finished inputting/ their
pattern.  So, if Icomplete starts computing essentially bogus
completions, because I'm still typing my initial input, I don't have to
do anything special to restart the search.

We can make this broader: instead of allowing the user to ignore
Icomplete just while inputting the initial pattern, I'd like to be able
to /ignore Icomplete until and unless I want to use its bindings/.
While I'm still inputting my initial pattern, I want to ignore Icomplete
because I'm not ready to complete.  Similarly, if I hit C-g to cancel
minibuffer input, I would like to be able to ignore Icomplete because,
again, I'm not interested in doing any completion.

Many instances of completing-read are invoked by the user in order to
enter arbitrary strings, and not to do any completion, even though it's
available.  I would like to be able to C-g out of these, as though
Icomplete weren't there at all, because I have no interest in using it.

However, as I described, if your C-g is unfortunately timed it gets
caught by the Icomplete computation and so doesn't exit the minibuffer.
Perhaps we can extend this so that it doesn't matter what moment the C-g
comes in.

-- 
Sean Whitton

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]

> 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