[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Emacs-trunk-diffs] Changes to emacs/src/sysdep.c
From: |
Stefan Monnier |
Subject: |
Re: [Emacs-trunk-diffs] Changes to emacs/src/sysdep.c |
Date: |
Sun, 05 Dec 2004 17:33:27 -0500 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) |
>>> What did you wish to do using emergency escape under a window system?
>> Get out of a infinite elisp loop executed while inhibit-quit is non-nil
>> (e.g. an infinite loop in a post-command-hook or a timer).
> I don't quite understand why it is assumed that everything run by
> a post-command-hook or a timer is a critical code not allowed to be
> interrupted with C-g?
The way existing code is written, allowing quit could lead to corrupted
states, so we can't just change it. Furthermore, the problem of
uninterruptible code is not limited to post-command-hook and timers.
So I'd rather have a general solution: a form of C-g that tries really hard
to interrupt the current code, even if it risks putting the process in
a somewhat corrupted state.
>> Yes, I can kill the Emacs process, but it's a real pity to have to do
>> that when there's nothing really wrong with it. Of course, all those
>> cases are bugs we should fix, but they do happen, sometimes while
>> writing/testing/debugging code.
> Is it a bug that regex.c can't detect long or infinite loops?
It can probably be considered as a performance bug (the complexity of regexp
matching should be O(n*m) where `n' and `m' are the size of the text and of
the regexp), but since we're not going to switch over to a different
algorithm any time soon (especially seeing as we're forking further away
from a clean non-Emacs-specific regexp.c), we just have to live with it.
As for "detection", it's basically impossible, no.
OTOH it shouldn't be too hard to obey C-g.
Stefan