bug#31692: Emacs sometimes drops key events

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

>> I don't understand the (throw 'throw-on-input t)
>> (throw throw-on-input t) would make more sense, but in any case we're
>> just about to exit that `catch` so throwing won't have any real effect.
> I hoped the comment explained that, but evidently not.

I think I understood the comment (and the email message before that ;-),
and your analysis makes a lot of sense, but AFAICT the "normal" way this
special quit-flag value is handled in the C code (see process_quit_flag
in src/eval.c) is to

   - read quit-flag
   - notice it's `eq`ual to the value of throw-on-input
   - set quit-flag to nil
   - throw to the flag's value

so the throw is not done to the constant symbol `throw-on-input` but to
the value of this variable, and the magic doesn't happen in response to
this throw (i.e. it's not done within the implementation of the
throw/catch code), but instead it happens before the throw.

As a consequence, instead of

    (throw 'throw-on-input t)

we need to throw like

    (throw throw-on-input t)

and we additionally need to (setq quit-flag nil) before that.

>> I think instead of (throw 'throw-on-input t) what is needed here is
>> 
>>     (setq quit-flag nil)
>> 
>> which will also make the body return nil (rather than t like (throw
>> throw-on-input t) would), which I believe is also the right thing.
>
> I believe we need to return t here, because input did arrive.

Indeed, I had missed that

So I suggest

    (progn (setq quit-flag nil) t)

We could also use (throw throw-on-input t) after the setq, but I don't
see the point since it seems it would give exactly the same result just
in a more costly way.


        Stefan