Re: How can I debug a problem triggered from jit-lock's background fontification?

[Daniel Colascione]

On 2/7/11 7:40 AM, Stefan Monnier wrote:
>> I have instrumented the CC Mode function for Edebug, yet something seems
>> to be inhibiting the invocation of Edebug from inside jit.  No doubt
>> there's a good reason for this, but it has been getting on my nerves for
>> years.

I've run into this problem as well.  I actually use lazy-lock for C and
C++ (because the deferred fontification seems to work better), and the
failure mode there even stranger: when breaking into edebug, emacs will
split the current window as many times as it can until something dies
from stack exhaustion.  I can usually recover from this situation by
switching to another buffer, killing the original, and killing the
excess windows, but it's quite annoying.

> Yes, the problem is that jit-lock is called when redisplay is needed so
> it's tricky to let Edebug work at this time (it's easy to make it work
> with redisplay inhibited, but then you'll need to use it blindly ;-).

What about redisplay to a tty frame?

>> Would somebody please suggest a way I can debug the actions of
>> jit-locking from Edebug, or possibly some other way of making progress.
> 
> I've had to deal with this problem, as you can imagine, and I feel
> your pain.  The way I generally handle this problem is as follows:

Speaking of which, quitting Emacs in the middle of a hard lisp loop
during redisplay on X11 (GTK and no-toolkit), nor OS X (AppKit) doesn't
seem to have any effect.  I've discovered that running under gdb,
breaking into Emacs with C-z, and setting debug_on_next_call to 1 works,
but it's cumbersome.  Is quitting during redisplay *supposed* to work?

signature.asc
Description: OpenPGP digital signature