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

[Stefan Monnier]

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

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 ;-).

> 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:
- first, try to turn off jit-lock and to reproduce the problem.  This is
  often all it takes, but admittedly, it doesn't always cut it.
- if that fails, then turn jit-lock back on, do M-x trace-function-background
  RET font-lock-fontify-region RET, and then try and reproduce the
  problem (try and be careful to make sure font-lock is only invoked in
  that one buffer during this time).
- if the trace itself doesn't give you enough of a hint (that's usually
  the case, but sometimes, just seeing where jit-lock placed the
  boundaries of its chunks is enough to see the problem), then turn off
  jit-lock again, and call font-lock-fontify-region by hand with the
  args recorded in the trace.  You can then use Edebug to your heart's
  content during this replay.
  I haven't had to do that often enough and with enough calls to
  font-lock-fontify-region to get me to automate this replay, but if you
  end up writing some code to automate it, I'd be happy to add it to
  jit-lock.
- if the above replay does not reproduce the problem, then you may want
  to try meditation.


        Stefan