* bug#17293: 24.4.50; C-g often fails in minibuffer under X
@ 2014-04-18 16:04 raman
2014-04-24 20:05 ` Stefan Monnier
0 siblings, 1 reply; 3+ messages in thread
From: raman @ 2014-04-18 16:04 UTC (permalink / raw)
To: 17293
I remember Stefan addressing this a while ago, but it appears to
bite me only when running under X.
Specifically:
When running under X (Ubuntu Precise) and using StumpWM as the
window manager (neither of those specific bits might be relevant)
often, if I have a minibuffer completion up, hitting C-g does
not dismiss the minibuffer, I actually have to switch away from
the minibuffer and type M-x top-level to get emacs back to being normal.
^ permalink raw reply [flat|nested] 3+ messages in thread
* bug#17293: 24.4.50; C-g often fails in minibuffer under X
2014-04-18 16:04 bug#17293: 24.4.50; C-g often fails in minibuffer under X raman
@ 2014-04-24 20:05 ` Stefan Monnier
2014-04-24 21:06 ` T.V Raman
0 siblings, 1 reply; 3+ messages in thread
From: Stefan Monnier @ 2014-04-24 20:05 UTC (permalink / raw)
To: raman; +Cc: 17293, T. V. Raman
> often, if I have a minibuffer completion up, hitting C-g does
> not dismiss the minibuffer, I actually have to switch away from
If you're in the minibuffer, then C-g should normally dismiss the
minibuffer, yes. Of course, we have the problem that C-g only does that
if it runs keyboard-quit (i.e. if Emacs was idle), and not if it signals
"quit" (i.e. Emacs was busy with something).
So apparently, there's been more cases where Emacs is "busy" (probably
just waiting in a sit-for or something). So to fix this, we need to
figure out what that C-g interrupts.
Stefan
^ permalink raw reply [flat|nested] 3+ messages in thread* bug#17293: 24.4.50; C-g often fails in minibuffer under X
2014-04-24 20:05 ` Stefan Monnier
@ 2014-04-24 21:06 ` T.V Raman
0 siblings, 0 replies; 3+ messages in thread
From: T.V Raman @ 2014-04-24 21:06 UTC (permalink / raw)
To: monnier; +Cc: tv.raman.tv, 17293, raman
Stefan, Makes sense.
I've been chasing a separate problem in emacs at work that is
keeping emacs busy --see below.
I run emacs-jabber to connect to Google Talk.
I have a large number of contacts there -- order of magnitude
100s -- many of whom constantly keep changing status.
emacs-jabber uses a continues fsm ping mechanism and if I leave
emacs idle ie dont touch the keyboard, profiler shows that emacs
is permanently busy in that handler. I've been trying various
advice tricks to keep that fsm tick from happening except when
jabber roster is selected, and surprize surprize that got the
c-g problem to diminish -- I could not figure out why till I saw
your note today.
Stefan Monnier writes:
> > often, if I have a minibuffer completion up, hitting C-g does
> > not dismiss the minibuffer, I actually have to switch away from
>
> If you're in the minibuffer, then C-g should normally dismiss the
> minibuffer, yes. Of course, we have the problem that C-g only does that
> if it runs keyboard-quit (i.e. if Emacs was idle), and not if it signals
> "quit" (i.e. Emacs was busy with something).
>
> So apparently, there's been more cases where Emacs is "busy" (probably
> just waiting in a sit-for or something). So to fix this, we need to
> figure out what that C-g interrupts.
>
>
> Stefan
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-04-24 21:06 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-04-18 16:04 bug#17293: 24.4.50; C-g often fails in minibuffer under X raman
2014-04-24 20:05 ` Stefan Monnier
2014-04-24 21:06 ` T.V Raman
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).