> As you can see, this function sometimes returns non-nil (i.e. it says it's
> found a match) but with no begin/end of match 0.
> Is that incorrect? If so, why did it appear to work ok before?
> Maybe the criterion for a bad match has to be written differently
> to accord with the practical rules for code that used to work.
> I'm tempted to just revert my patch, since it causes constant run-time
> checks and trips up some pre-existing code, only in the hope of
> occasionally
> working around some bugs that would need to be fixed anyway.
> No, don't do that! Let's see if adapting a little is better.
> Those bugs are rather painful.
I've never bumped into this specific form of an infinite
non-interruptible computation. So maybe they're painful but they seem to be
much more rare than other similar problems not addressed by the patch.
The most common such problem by far is when a regexp hits a pathological
exponential-matching behavior. I wish we'd fix that one instead.
Also, they're only painful because of Emacs's lack of NMI. I'd rather fix
that part instead. E.g. when C-g is pressed, record the time, and if a C-g
is pressed again 2 seconds later and the first hasn't been processed yet,
then ignore the inhibit-quit flag (i.e. set it back to nil).
Stefan
_______________________________________________
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
