emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: font-lock is broken


From: Stefan Monnier
Subject: Re: font-lock is broken
Date: Tue, 19 Jul 2005 10:20:17 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

>     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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]