Re: [Emacs-trunk-diffs] Changes to emacs/src/sysdep.c

[Stefan Monnier]

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