GNU bug report logs -
#31692
aggressive-indent-mode causes Emacs to sometimes drop key events
Previous Next
Full log
View this message in rfc822 format
>> 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
This bug report was last modified 7 years and 34 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.