bug#31692: Emacs sometimes drops key events

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't think I understand what you mean by "not propagated".  The
> documentation says that if input arrives, the forms in the body of
> while-no-input are _aborted_ as if by interrupt.

Yes, those in the _body: of while-no-input.  But not those in the
outside scope, which is what is happening here also.

> > I also read the documentation of the
> > low-level tools with which this is implemented - `throw-input' and
> > `quit-flag', and that also gives me the impression that generating a
> > "quit" signal is not intended (that would also be not very useful).  We
> > only want a quit to come through when the user really quits (C-g) -
> > that's while `while-no-input' (which uses `with-local-quit' that sets
> > `quit-flag') explicitly quit - but only when a quit had been
> > intercepted.
>
> But in your case while-no-input was the top-level form, no?  So where
> else can a quit throw?

There should be no quit at all.  `throw-on-input' uses a special value
`quit-flag' internally to implement what it does, but AFAIU signaling a
real quit is not intended.

In my example, `test' was the top-level form, and I would expect that
`while-no-input' completes normally, which it doesn't in this case.
This case is the only one I know of where `while-no-input' is left with
an nonlocal exit.  AFAIU `while-no-input' is also not meant to consume
user input, and `sit-for' also should not do this.  Only the combination
of the two shows this behavior.


Michael.