From: Daniel Colascione <dan.colascione@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Alan Mackenzie <acm@muc.de>, emacs-devel@gnu.org
Subject: Re: How can I debug a problem triggered from jit-lock's background fontification?
Date: Mon, 07 Mar 2011 23:58:05 -0800 [thread overview]
Message-ID: <4D75E18D.4010009@gmail.com> (raw)
In-Reply-To: <jwv7hdbj23p.fsf-monnier+emacs@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 1663 bytes --]
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?
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
next prev parent reply other threads:[~2011-03-08 7:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-06 20:54 How can I debug a problem triggered from jit-lock's background fontification? Alan Mackenzie
2011-02-07 15:40 ` Stefan Monnier
2011-02-07 22:19 ` Alan Mackenzie
2011-02-07 22:22 ` Lennart Borgman
2011-03-08 8:02 ` Daniel Colascione
2011-03-08 7:58 ` Daniel Colascione [this message]
2011-03-08 21:07 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D75E18D.4010009@gmail.com \
--to=dan.colascione@gmail.com \
--cc=acm@muc.de \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).