[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Redisplay hook error bactraces [Was: Fontification error backtrace]
From: |
Eli Zaretskii |
Subject: |
Re: Redisplay hook error bactraces [Was: Fontification error backtrace] |
Date: |
Wed, 13 Jul 2022 15:33:07 +0300 |
> Date: Tue, 12 Jul 2022 19:48:49 +0000
> Cc: larsi@gnus.org, Stefan Monnier <monnier@iro.umontreal.ca>,
> emacs-devel@gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
>
> To use it, set the variable backtrace-on-redisplay-error to t.
There's no such variable in the patch.
> Optionally, configure redisplay-last-error, which determines which
> backtrace(s) to keep, should a command cause more than one.
Why do we need two variables for that? why not a single variable that
is not a boolean?
> > > 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.
>
> I've tried to use it, but the list of warnings does indeed wait until
> after the next command before being displayed.
I think it's a terminology issue: how do you define "next command" in
this context?
I'm telling you: we have code in the display engine that uses delayed
warnings, and the warnings pop up right away, not after one more
command.
> > > 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.
>
> The "handling" of the error is to allow the redisplay to continue, just
> as though no backtrace were generated. Since there's no possibility of
> user interaction or a recursive redisplay, that should be OK.
I don't understand this response. It seems to be unrelated to what I
wrote.
> > > 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.
>
> Sorry, I didn't express that well. That variable redisplay_deep_handler
> merely records the handler that a condition-case might use. In
> signal_or_quit, if the handler about to be used matches
> redisplay_deep_handler, then a backtrace gets generated.
??? You use a handler as a flag? Then why not just use a simple flag
variable?
> + /* 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)))
Why do we need so many conditions and flags? Why do we need a new
variable redisplay_lisping, when we already have redisplaying_p? Why
do you need to compare both redisplay_deep_handler and
backtrace_on_redisplay_lisp_error? And what is the test of
backtrace_yet about?
I still hope this could be done more elegantly and with fewer changes
to infrastructure.
Thanks.
- Redisplay hook error bactraces [Was: Fontification error backtrace], Alan Mackenzie, 2022/07/12
- Re: Redisplay hook error bactraces [Was: Fontification error backtrace],
Eli Zaretskii <=
- 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, 2022/07/13
- 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