Re: Redisplay hook error backtraces

[Eli Zaretskii]

> Date: Wed, 13 Jul 2022 18:41:01 +0000
> Cc: larsi@gnus.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> The problem is that other signals go through the same C code in
> signal_and_quit, for example "smaller" condition-cases.  We do not want
> to generate backtraces for these routine condition-cases which simply get
> handled by their Lisp code.  redisplay_deep_handler records the "deepest"
> pending condition-case, and only if the variable `h' matches that deepest
> condition case do we have an error that we want to output a backtrace for.

I still don't think I understand why testing redisplaying_p and the
new optional variable would not be enough.

> > And what is the test of backtrace_yet about?
> 
> When a backtrace is being generated, it first erases *Backtrace*.  We
> only want to do that for the first backtrace generated by the current
> command.  So backtrace_yet records whether we've already generated a BT
> in this command.  It is reset to false in the command loop.
> 
> This ensures that the user sees that first backtrace, which is
> likely to be the most interesting one.  Unless she has configured
> backtrace-last-error to do something different.
> 
> As an alternative to this complicated configuration, perhaps we could
> just erase *Backtrace* for the first BT, then write any further BTs to
> *Backtrace*, too.

Either that, or erase it every time.  I think anything more complex is
over-engineered.

> > I still hope this could be done more elegantly and with fewer changes
> > to infrastructure.
> 
> You mean, all the changes in eval.c and keyboard.c?  I think the changes
> to internal_condition_case_n are essential to the patch, and I honestly
> don't think it can be done much more elegantly, but I'm open to
> suggestions.

Can we discuss how to implement it without introducing a special
handler and without adding new safe_run_hooks_* functions?