[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fontification error backtrace [Was: Why is it so difficult to get a

From: Stefan Monnier
Subject: Re: Fontification error backtrace [Was: Why is it so difficult to get a Lisp backtrace?]
Date: Thu, 30 Jun 2022 16:34:23 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

>> That's where we currently log all the errors during redisplay, since
>> Emacs 21.1.  So why this one is different?
> It's not a single line, or a small number of lines.  It could potentially
> be a stack overflow error, generating a large backtrace, which might have
> more lines than message-log-max.

How 'bout stashing the backtrace data in a var (without turning it into
text yet; that should always be quick, safe, and painless) and then
adding a button in the *Messages* (or *Warnings*) next to the error
itself such that pressing the buttong shows you the actual backtrace?

We could even try and get fancy: instead of only stashing the
`backtrace-frames`, we could also stash a copy of the specpdl so we
could bring up a *Backtrace* buffer which isn't quite "live" but can
still be used to some extent to see the values of local vars (and
`current-buffer`) in the different activation frames.

BTW, in order to debug fontification errors, we also have
`jit-locak-debug-mode` which postpones the jit/font-lock execution from
within redisplay to "just a bit later" such that it can use the
debugger.  IIRC it still has some rough edges in some cases, but in
theory it should be possible to make this work such that you can (for
example) Edebug `font-lock.el` itself.


reply via email to

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