[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
question about `sit-for' and `C-g'
From: |
Drew Adams |
Subject: |
question about `sit-for' and `C-g' |
Date: |
Fri, 11 May 2012 15:46:50 -0700 |
I have some code that, during minibuffer completion, sometimes shows something
in the mode line for a `sit-for' period (user-configurable). `sit-for' calls
`read-event' and, except for prefix-arg keys, supposedly pushes the input event
back onto `unread-command-events'.
If the user hits `C-g' during the `sit-for' period, then, instead of the `C-g'
binding in effect in the minibuffer being respected, it seems like
`sit-for'/`read-event' handles the `C-g' event directly (?).
The effect, in any case, seems to be this: (a) `ding' (the bell rings, with the
message `Quit') and (b) the `C-g' gets lost/ignored, so the user needs to hit
`C-g' again to get the normal minibuffer `C-g' behavior. AFAICT, there is no
actual quit effected - no SIGQUIT, but there are its indications: bell, message.
Certainly, the `C-g' binding in effect in the minibuffer is ignored.
Dunno whether the `C-g' event is ignored/lost, or it is (mis)handled only by
dinging and saying `Quit'. It shouldn't be ignored/lost, since the `sit-for'
code apparently pushes it to `unread-command-events'. It's not clear to me just
what is happening, but I'm sure that something other than my code (directly, at
least) is ringing the bell and writing `Quit'.
I have only the Emacs 23.3 C code, but it is perhaps the same for Emacs 24
`read-event' etc. That function calls `read_filtered_event', and I don't see
anything in that function that handles `C-g' specially.
Except that `read_filtered_event' calls `read_char', which does seem to do
something wrt the quit char (C-g), at least in some cases. It's not clear to me
just what it does, but if I had to guess it would be that this might be where
the `C-g' is ringing the bell and getting swallowed up.
I'm no expert when it comes to C code, clearly. Perhaps someone can clue me in.
What am I missing? What is handling this C-g during `sit-for'? And should it
be? Should `sit-for' handle `C-g' its own way, ignoring any `C-g' binding? (I
understand that `read-event' should do so, but I wonder about `sit-for'.)
Anyway, besides helping me understand what's happening, what's the best way to
get the `C-g' here handled normally (i.e., as a `C-g' in the minibuffer
keymaps)? I guess I could call a substitute for `sit-for' that tests the
char/event read and explicitly DTRT for `C-g'. Is that what you would
recommend, or should `sit-for' itself perhaps do something different/better?
(`sit-for' already handles prefix-arg keys specially.)
If I had to guess, after reading this over, it would be that you'll say that
`sit-for', like `read-event', should not itself handle `C-g' in the normal way
(i.e., pass it along, respecting its current key binding), and that it should,
like `read-event', treat `C-g' in a hard-coded way. I'd still like to hear
about this (explanation, reasons, etc.), so I can understand better.
Thx.
- question about `sit-for' and `C-g',
Drew Adams <=