unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Jason S. Cornez" <jcornez@ravenpack.com>
To: 6585@debbugs.gnu.org
Subject: bug#6585: 23.1; Hang / CPU 100% on background interaction when in minibuffer
Date: Tue, 31 Aug 2010 12:34:30 +0200	[thread overview]
Message-ID: <4C7CDAB6.3090308@ravenpack.com> (raw)
In-Reply-To: <jwvpqwzgk42.fsf-monnier+emacs@gnu.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yes, I agree about fixing the elisp code - indeed this has been done.
But what about when the code isn't mine, but is in some library I happen
to be using?  Again, the right solution is always to fix the code, but
that might not be possible for the end user of emacs to do.

But I find it difficult to accept that emacs gets wedged like it does. I
love emacs and having to kill the process from the OS is just so, so
sad.  I would love a C-g C-g C-g option (just like there is ESC ESC
ESC).  And it would be even better if this could work in conjunction
with some flag so that it pops me into the debugger and I can see what
function I've broken out of.

So again, I know the elisp code was broken.  But I still say that emacs
is broken since it is currently impossible to salvage the situation.
Yes, it is a sign of a bug somewhere - and I want emacs to help me find
it, or at least escape from it.

Thanks for your consideration,
- -Jason

On 08/31/2010 12:24 PM, Stefan Monnier wrote:
>> Of course, fixing the elisp function is easy and that simply and
>> effectively avoids this problem.  Still, I find it disconcerting that I
>> can lockup emacs in such a manner.
> 
> All code run from timers and from (post|pre)-command-hook (as well as
> jit-lock, filters, and a few other things) is run with inhibit-quit set
> to t because the user may not know this code is running so if she hits
> C-g it "probably" means she wants to interrupt something else.
> 
> It's not broken.  Basically, the problem is in your code: such async
> code should not run for indefinite amount of time, whereas your code may
> inf-loop.
> 
> 2 solutions:
> - fix your code so it doesn't inf-loop (usually the best solution).
> - wrap your code in with-local-quit to let C-g interrupt it.
> 
> Admittedly, Emacs should also additionally understand something like C-g
> C-g C-g C-g as a sign that the user is getting impatient and we should
> thus ignore the inhibit-quit flag.  But such a case is always a sign of
> a bug somewhere.
> 
> 
>         Stefan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkx82rYACgkQQlm6HDTMLyPZZwCgu6ONheghjKDSYg0Ra5j0+rFt
EPYAoNR1225PzzmNFl34bgThRGijd/HW
=bUAm
-----END PGP SIGNATURE-----





  reply	other threads:[~2010-08-31 10:34 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-08 14:19 bug#6585: 23.1; Hang / CPU 100% on background interaction when in minibuffer Jason Cornez
2010-07-08 16:52 ` Eli Zaretskii
2010-07-09  7:06 ` Jason S. Cornez
2010-07-14 10:27 ` Jason S. Cornez
     [not found] ` <handler.6585.B.12786062373280.ack@debbugs.gnu.org>
2010-07-15 12:05   ` Jason S. Cornez
2010-07-15 14:57     ` martin rudalics
2010-07-15 15:33       ` Jason S. Cornez
2010-07-16  8:27         ` martin rudalics
2010-07-16  8:39           ` Jason S. Cornez
2010-07-15 15:53     ` Johan Bockgård
2010-07-15 15:59       ` Jason S. Cornez
2010-08-31  6:42 ` Jason S. Cornez
2010-08-31 10:24   ` Stefan Monnier
2010-08-31 10:34     ` Jason S. Cornez [this message]
2010-08-31 13:09       ` Stefan Monnier
2010-08-31 15:09         ` Jason S. Cornez
2012-04-10 19:37           ` Stefan Monnier
2010-09-13 13:22 ` bug#6585: Patch welcome? Jason S. Cornez
2010-09-13 15:55   ` Stefan Monnier
2011-11-21 22:54 ` bug#6585: status of patch? Tim Connors
2011-11-22 21:47   ` Stefan Monnier
2011-11-23  7:02     ` Jason S. Cornez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C7CDAB6.3090308@ravenpack.com \
    --to=jcornez@ravenpack.com \
    --cc=6585@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).