emacs-devel
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]