bug#34535: 27.0.50; emacs -nw: while-no-input + sit-for + <KEY> => Quit

[Eli Zaretskii <eliz@gnu.org>]

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