[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#34535: 27.0.50; emacs -nw: while-no-input + sit-for + <KEY> => Quit
From: |
Eli Zaretskii |
Subject: |
bug#34535: 27.0.50; emacs -nw: while-no-input + sit-for + <KEY> => Quit |
Date: |
Fri, 22 Feb 2019 18:08:58 +0200 |
> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Mon, 18 Feb 2019 23:29:04 +0100
>
> in emacs -nw -Q eval in any way
>
> (while-no-input (sit-for 20))
>
> and hit any key before the sit-for terminates. This always gives me a
> Quit. That should not happen.
On the emacs-26 branch, we have bug#31692, so this cannot work
correctly there. That bug is fixed on master, though.
What happens on master is this: when sit-for is called inside
while-no-input on a TTY, it returns the cons cell (t . ?\C-g), which
then causes keyboard quit right after while-no-input returns.
The below seems to fix the problem, but I hope you also have a more
complex real-life use case, because I'm not really sure this solution
has no adverse effects elsewhere.
Stefan, any thoughts?
diff --git a/src/keyboard.c b/src/keyboard.c
index 1d67c3e..4448e2b 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -2551,7 +2551,10 @@ read_char (int commandflag, Lisp_Object map,
restore_getcjmp (save_jump);
pthread_sigmask (SIG_SETMASK, &empty_mask, 0);
unbind_to (jmpcount, Qnil);
- XSETINT (c, quit_char);
+ /* If we are in while-no-input, don't trigger C-g, as that will
+ quit instead of letting while-no-input do its thing. */
+ if (!EQ (Vquit_flag, Vthrow_on_input))
+ XSETINT (c, quit_char);
internal_last_event_frame = selected_frame;
Vlast_event_frame = internal_last_event_frame;
/* If we report the quit char as an event,