[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Redisplay hook error backtraces
From: |
Alan Mackenzie |
Subject: |
Re: Redisplay hook error backtraces |
Date: |
Wed, 13 Jul 2022 20:12:42 +0000 |
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).
- Redisplay hook error bactraces [Was: Fontification error backtrace], Alan Mackenzie, 2022/07/12
- Re: Redisplay hook error bactraces [Was: Fontification error backtrace], Eli Zaretskii, 2022/07/13
- Re: Redisplay hook error backtraces, Alan Mackenzie, 2022/07/13
- Re: Redisplay hook error backtraces, Eli Zaretskii, 2022/07/13
- Re: Redisplay hook error backtraces,
Alan Mackenzie <=
- Re: Redisplay hook error backtraces, Stefan Monnier, 2022/07/13
- Re: Redisplay hook error backtraces, Eli Zaretskii, 2022/07/14
- Re: Redisplay hook error backtraces, Alan Mackenzie, 2022/07/14
- Re: Redisplay hook error backtraces, Eli Zaretskii, 2022/07/14
- Re: Redisplay hook error backtraces, Alan Mackenzie, 2022/07/14
- Re: Redisplay hook error backtraces, Eli Zaretskii, 2022/07/14
- Re: Redisplay hook error backtraces, Alan Mackenzie, 2022/07/14
- Re: Redisplay hook error backtraces, Stefan Monnier, 2022/07/14
- Re: Redisplay hook error backtraces, Alan Mackenzie, 2022/07/14
- Re: Redisplay hook error backtraces, Stefan Monnier, 2022/07/14