[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How can I debug a problem triggered from jit-lock's background fonti
From: |
Stefan Monnier |
Subject: |
Re: How can I debug a problem triggered from jit-lock's background fontification? |
Date: |
Tue, 08 Mar 2011 16:07:31 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
> 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
Note that lazy-lock is slated for removal (probably before Emacs-25.1).
>> 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?
Same difference, since they also support faces.
> 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?
The Elisp code that is not run in direct response to a user event
(pre/post-command-hook, redisplay, process filters, timers, ...) is run
with inhibit-quit set to t, since the user may hit C-g without knowing
that this code is running, i.e. without intending to interrupt
this code. There's a pending suggestion to let a C-g C-g C-g override
this, but I haven't looked at the patch yet :-(
Stefan