Re: Redisplay hook error bactraces [Was: Fontification error backtrace]

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Wed, Jul 13, 2022 at 15:13:41 -0400, Stefan Monnier wrote:
> > +  /* If an error is signalled during a Lisp hook in redisplay, write a
> > +     backtrace into the buffer *Backtrace*.  */
> > +  if (!debugger_called && !NILP (error_symbol)
> > +      && redisplay_lisping
> > +      && backtrace_on_redisplay_lisp_error
> > +      && (!backtrace_yet || !NILP (Vredisplay_last_error))
> > +      && (NILP (clause) || h == redisplay_deep_handler)
> > +      && NILP (Vinhibit_debugger)
> > +      && !NILP (Ffboundp (Qdebug_early)))
> > +    {
> > +      max_ensure_room (&max_lisp_eval_depth, lisp_eval_depth, 100);
> > +      specpdl_ref count = SPECPDL_INDEX ();
> > +      ptrdiff_t counti = specpdl_ref_to_count (count);
> > +      AUTO_STRING (backtrace, "*Backtrace*");
> > +      Lisp_Object backtrace_buffer;
> > +      AUTO_STRING (gap, "\n\n\n\n"); /* Separates backtraces in *Backtrace* */

> I really think that printing the backtrace right when the error is
> signaled is a bad idea.  Better just copy the whole specpdl (or just the
> backtrace part of it) and leave the buffer manipulation and printing for
> later when we're back in a normal&sane context.

What you suggest would imply a _lot_ of coding to make it happen.  Does
there exist anywhere any support for copyging a specpdl, and somehow
making a lisp object out of it?  Why do you think that copying the
specpdl would be less work or less risky than directly generating a
backtrace, as the current code does?

The advantage of directly generating the backtrace is that all the
infrastructure is already there.  We've got mapbacktrace which
encapsulates the formats of the specpdl.  And debug-early.el, whose two
functions total 60 lines (including doc strings and comments) and don't
use any other Lisp whatsoever.

> It would be worthwhile doing all this work in the context of the error
> if there was an upside such as the ability to do the debugging "live",
> but since this is for the case where we'll be doing a "post-mortem
> debugging" anyway, we're much better off doing as little as possible in
> the context of the error: too many things can go wrong when running in
> the context of the error, it's asking for trouble.

Again, why is copying the pdl less risky than generating the backtrace?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).