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

[Eli Zaretskii]

> Date: Tue, 28 Jun 2022 19:31:59 +0000
> Cc: larsi@gnus.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > *Messages* just doesn't feel the right place to put a backtrace.
> 
> > 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.

We could temporarily bind message-log-max to a larger value, if that's
the problem.  But I really doubt that something like this could be an
issue in practice.

> > But you _really_ dislike *Messages*, then put the stuff into another
> > buffer, like *backtrace-in-redisplay* or somesuch.
> 
> I'm currently using the buffer *Backtrace*.  Is there anything wrong with
> that?

Not that I see, no.

> > The buffer with warnings pops up very soon after redisplay, which is
> > more-or-less exactly what you wanted?
> 
> OK, I've never used it.  On reading the documentation, I expected it to
> wait until after the next command.

That's because the ELisp reference manual describes it from the POV of
setting up the warning as part of some command.  And even then, it
says:

     The value of this variable is a list of warnings to be displayed
     after the current command has finished.

"Current command", not "next command".

If you add a warning to the list inside redisplay, it will pop up
after redisplay returns.

> Now I remember why I created the backtrace in signal_or_quit - it needs
> to be done before the stack gets unwound, which happens later in
> signal_or_quit.  On return to save_eval_handler is just too late for
> this.

That's orthogonal, I think?  You can collect the data inside
signal_or_quit, and the signal handler then only needs to handle the
error gracefully after it adds the warning.

> > It will, because any Lisp we call goes though safe_eval.  The only
> > reason why your original proposal didn't was because it bound the
> > variable which enables this only in handle_fontified_prop.  But we
> > don't need this flag if the logic to decide what to do with the error
> > will be in save_eval_handler.
> 
> Then the mechanism I've implemented, namely to set redisplay_deep_handler
> to the handler which would handle an error, could be made to serve for
> other sorts of Lisp code.

It could, but I see no reason for having a new handler.

> > And you need to consider one more factor: code from display engine,
> > including fontification via handle_fontified_prop, is called also from
> > user commands, not via redisplay_internal.  For example, commands like
> > C-n and C-v invoke display code.  Errors signaled there _can_ be left
> > to go to top-level and probably could call the debugger.  To test
> > whether any given code was called from redisplay_internal, test the
> > value of the variable redisplaying_p.
> 
> OK, this is a further complication.  But it would be good to get to the
> debugger if possible, rather than just having a "historical" backtrace.

If the display code is called from "normal" commands, you can.