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>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  34535@debbugs.gnu.org
> Date: Sat, 23 Feb 2019 05:27:36 +0100
> 
> This seems fixed for me with your patch.

Thanks for testing.  I'll push the change in a few days, if nothing
pops up to the contrary.

> In real real life, I made it so that while-no-input only covers the
> computation needed for the minibuffer hint (counting matches) which must
> be interruptible, but not the sit-for used to delay the minibuffer hint
> being removed.  That sit-for was inside while-no-input originally was a
> matter of laziness, I was able to rewrite it to circumvent the issue.

Please note that using while-no-input with BODY that reads some input
in a way causes indeterminate results, because whether the arriving
input will be read and consumed by BODY and/or used to throw control
flow out of BODY, depends on seemingly random factors, like whether
Emacs checks quit-flag before or after BODY consumes the input and
acts upon it.

For example, in your test case:

  (while-no-input (sit-for 20))

there's a conceptual difficulty in deciding whether pressing a key
during the 20-sec wait should return nil or t.  On the one hand,
arriving input should end BODY and return t, but OTOH that same input
causes sit-for to stop waiting, so BODY finishes, and while-no-input
should return what sit-for returned, i.e. nil.  What actually happens
depends on the underlying implementation, which is sometimes
platform-dependent, and on what a more complex BODY does.

IOW, I think while-no-input does not (and cannot) reliably produce
deterministic output in the case where BODY itself reads input.  We
try to DTRT, but there can be no general guarantees in these cases.