Re: Redisplay hook error backtraces

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Wed, Jul 13, 2022 at 22:00:14 +0300, Eli Zaretskii wrote:
> > 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.

We've got to distinguish between the signals we want to generate
backtraces for and those we don't.  redisplaying_p is not relevant to
that, I think.  For example, we don't want to generate a backtrace for a
"failed" evaluation of the code generated by `c-safe'.

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

OK, I'll get rid of the config variable, and just dump every backtrace to
*Backtrace*.  That will get rid of quite a few lines of code.

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

OK.  Perhaps with extra optional arguments, that kind of thing?

-- 
Alan Mackenzie (Nuremberg, Germany).