emacs-devel
[Top][All Lists]
Advanced

[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



reply via email to

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