bug#7722: 24.0.50; Finding this C++ header file drops emacs into a infinite loop

[Alan Mackenzie]

Hi, Yidong!

On Fri, Feb 11, 2011 at 08:25:06PM -0500, Chong Yidong wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > It was indeed such a loop.  It was caused by a 500n jit-lock boundary
> > falling in the middle of a template construct, hence the "necessity" of
> > all the whitespace to reproduce the failure.

> > Here's a putative patch for the problem.  I've refactored the offending
> > function by replacing obscenely nested `if'-forms with a simple `cond'.
> > I've also removed some narrowing (to the 500n limit) which should help
> > jit-lock, hopefully without hurting too much elsewhere.

> > Tassilo, would you try out the patch, please, and let me know how it
> > goes.  Thanks!

> Thanks.  This patch doesn't apply cleanly to the emacs-23 branch.

That surprises me.  Would you like me to rework the patch so that it
does?

> Do you think we could apply it to the trunk, and just use the
> workaround in the branch ....

To be honest, I haven't really looked at the workaround.  I suppose it
would be OK.  However, the patched version passed all the CC Mode
regression tests (which are about half indentation, half font-locking),
so I'm fairly confident about it.

> .... (some of these logic changes don't look obvious to me)?

One of the fixes was removing a `narrow-to-region' around the region
being fontified.  In a jit-lock 500-byte chunk, this had the effect of
cutting necessary context off the end.

The other change was basically to refactor, in which the infinite looping
disappeared in the wash.  Although I could get edebug going on this loop,
the source was just too complicated to be worthwhile trying to understand
in detail.  (Believe me, I tried.  :-)

Incidentally, I'm not getting mail from emacs-devel or bug-gnu-emacs at
the moment, and I've not got enough energy to do anything about it.  Do
you know anything specific which might be doing this to me?

-- 
Alan Mackenzie (Nuremberg, Germany).