From: Eli Zaretskii <eliz@gnu.org>
To: Alan Mackenzie <acm@muc.de>
Cc: larsi@gnus.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: Redisplay hook error bactraces [Was: Fontification error backtrace]
Date: Wed, 13 Jul 2022 15:33:07 +0300 [thread overview]
Message-ID: <837d4hw5to.fsf@gnu.org> (raw)
In-Reply-To: <Ys3QIdoEqrFXMCKj@ACM> (message from Alan Mackenzie on Tue, 12 Jul 2022 19:48:49 +0000)
> 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.
next prev parent reply other threads:[~2022-07-13 12:33 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-25 13:42 Why is it so difficult to get a Lisp backtrace? Alan Mackenzie
2022-06-25 15:26 ` Alan Mackenzie
2022-06-25 15:30 ` Stefan Kangas
2022-06-25 15:52 ` Alan Mackenzie
2022-06-25 16:27 ` Stefan Kangas
2022-06-25 15:35 ` Lars Ingebrigtsen
2022-06-25 15:59 ` Alan Mackenzie
2022-06-25 16:51 ` Eli Zaretskii
2022-06-25 19:45 ` Alan Mackenzie
2022-06-26 5:20 ` Eli Zaretskii
2022-06-27 19:48 ` Fontification error backtrace [Was: Why is it so difficult to get a Lisp backtrace?] Alan Mackenzie
2022-06-28 11:43 ` Lars Ingebrigtsen
2022-06-28 11:57 ` Eli Zaretskii
2022-06-28 17:28 ` Alan Mackenzie
2022-06-28 18:17 ` Eli Zaretskii
2022-06-28 19:31 ` Alan Mackenzie
2022-06-29 19:00 ` Eli Zaretskii
2022-07-12 19:48 ` Redisplay hook error bactraces [Was: Fontification error backtrace] Alan Mackenzie
2022-07-13 12:33 ` Eli Zaretskii [this message]
2022-07-13 18:41 ` Redisplay hook error backtraces Alan Mackenzie
2022-07-13 19:00 ` Eli Zaretskii
2022-07-13 20:12 ` Alan Mackenzie
2022-07-13 20:49 ` Stefan Monnier
2022-07-14 5:12 ` Eli Zaretskii
2022-07-14 9:01 ` Alan Mackenzie
2022-07-14 9:10 ` Eli Zaretskii
2022-07-14 13:42 ` Alan Mackenzie
2022-07-14 13:59 ` Eli Zaretskii
2022-07-14 16:07 ` Alan Mackenzie
2022-07-14 16:18 ` Stefan Monnier
2022-07-14 19:47 ` Alan Mackenzie
2022-07-14 20:48 ` Stefan Monnier
2022-07-15 5:50 ` Eli Zaretskii
2022-07-15 18:18 ` Alan Mackenzie
2022-07-16 6:03 ` Eli Zaretskii
2022-07-14 17:09 ` Eli Zaretskii
2022-07-14 19:33 ` Alan Mackenzie
2022-07-16 6:12 ` Eli Zaretskii
2022-07-16 15:45 ` Alan Mackenzie
2022-07-13 19:13 ` Redisplay hook error bactraces [Was: Fontification error backtrace] Stefan Monnier
2022-07-13 19:24 ` Eli Zaretskii
2022-07-13 19:58 ` Alan Mackenzie
2022-07-13 20:45 ` Stefan Monnier
2022-06-30 20:34 ` Fontification error backtrace [Was: Why is it so difficult to get a Lisp backtrace?] Stefan Monnier
2022-07-01 5:39 ` Eli Zaretskii
2022-07-01 15:34 ` Juri Linkov
2022-07-01 16:04 ` Eli Zaretskii
2022-07-01 19:14 ` Juri Linkov
2022-07-01 19:26 ` Stefan Monnier
2022-07-02 5:53 ` Eli Zaretskii
2022-07-02 21:15 ` Stefan Monnier
2022-07-02 20:27 ` Alan Mackenzie
2022-07-02 21:12 ` Stefan Monnier
2022-06-26 8:45 ` Why is it so difficult to get a Lisp backtrace? Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=837d4hw5to.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=acm@muc.de \
--cc=emacs-devel@gnu.org \
--cc=larsi@gnus.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.