bug#31692: Emacs sometimes drops key events

[Michael Heerdegen <michael_heerdegen@web.de>]

Eli Zaretskii <eliz@gnu.org> writes:

> Not necessarily.  The forms of the body are aborted, as documented,
> and that includes discarding all input, so the character that
> interrupted while-no-input gets discarded as well.

I don't think discarding input is intended.  If you replace `sit-for' by
something else (a loop causing a delay, or a sleep for), it doesn't
discard the input.

> > For `aggressive-indent-mode' - I think they should use an idle timer:
> > Add something to `post-command-hook' that activates the timer, or
> > resets
> > the idle time when the timer is already there.  When the timer fires,
> > you don't need `sit-for' - and the problem only occurs when
> > `while-no-input' and `sit-for' are combined.  The timer just calls the
> > aggressive indent function wrapped in `while-no-input'.
>
> I actually don't understand why not use just sit-for.  Why is
> while-no-input needed on top of that?

Seems you never used `while-no-input', or at least not for the same
things as I did.

AFAIU the purpose of `while-no-input' is to make frequently occurring
"background" operations that last long enough to possibly interfere with
user interaction interruptable: hitting a key aborts the operation and
the editor is corresponding without delay.  And the command
corresponding to the hitten key is executed as normal.  Of course you
need to ensure that the aborted code always leaves thing in a consistent
state.

An automatic indent mode is a good example: you potentially want
re-indenting after any editing operation, but it is potentially slow and
would cause delays.  Using `while-no-input' let's you interrupt the
indentation operation and continue typing.  If you later make a long
enough typing pause, indentation will finish.  The `sit-for' is there to
avoid that indenting fires immediately after hitting a key, so that
interrupts are less common.

That's what I think is the purpose of `while-no-input'.  I use it here
and there, and never saw the behavior we see here.  It seems this only
happens if a `sit-for' is aborted inside the scope of a
`while-no-input'.


Michael.