[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: Alan Mackenzie
Subject: Re: Fontification error backtrace [Was: Why is it so difficult to get a Lisp backtrace?]
Date: Sat, 2 Jul 2022 20:27:32 +0000

Hello, Stefan.

On Thu, Jun 30, 2022 at 16:34:23 -0400, Stefan Monnier wrote:
> >> 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 .....

Does "that" mean the stashing or the turning into text?

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

I'm not sure the stashing of the backtrace data is a good idea.  It's
likely to be BIG (see above), and it's fragile - the only place to
record it is in signal_or_quit, before it gets discarded by a call to
unwind_to_catch.  The need to know its precise format is obviated by the
C function mapbacktrace, so we might as well just dump out the backtrace
as text in *Backtrace* at the first opportunity.  There's nothing time
critical about the said dumping.

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

I think that's very ambitious.  Surely the time for that is when the
basic backtrace functionality is working, and the need for something
more sopisticated is perceived.

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

It does work, though, doesn't it?

>         Stefan

Alan Mackenzie (Nuremberg, Germany).

reply via email to

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