[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: |
Thu, 14 Jul 2022 19:33:09 +0000 |
Hello, Eli.
On Thu, Jul 14, 2022 at 20:09:02 +0300, Eli Zaretskii wrote:
> > Date: Thu, 14 Jul 2022 16:07:33 +0000
> > Cc: larsi@gnus.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>
> > > There's just one condition-case available to Lisp code, AFAICT, so why
> > > isn't it enough to distinguish condition-case from any other callers of
> > > internal_condition_case* ?
> > I think I understand what you're saying, now. That a condition-case
> > called from Lisp will not use any of the internal_condition_case*
> > functions. So we could just assume that if i_c_case* triggers, it must be
> > one of the hooks we're interested in that called it.
> > I don't think that's right. It might well be that Lisp code calls a C
> > primitive function that itself uses an internal_condition_case. In this
> > scenario, we would not want to generate a backtrace for that nested
> > internal_condition_case.
> And we won't, because redisplaying_p won't be set.
I don't understand. If redisplay is called normally, it will go through
redisplay_internal which sets redisplaying_p to true. And it will stay
true till the end of redisplay_internal, unless one of two special things
happen: (i) We enter the debugger; (ii) there's a recursive edit.
I don't see how the new backtrace facility can get any useful information
out of redisplaying_p; if there were a nested internal_condition_case*,
redisplaying_p would still be true, surely?
What am I missing?
> > > > I disagree. There are seven places, for the seven different Lisp hooks
> > > > currently called from redisplay.
> > > Aren't they all go through safe_call?
> > They do, yes, but so do other things that we don't want to engage the
> > backtrace mechanism for.
> > > Which seven places are you talking about?
> > 1. handle_fontified_prop;
> > 2. set_message;
> > 3. clear_message;
> > 4. prepare_menu_bars (near the top);
> > 5. update_menu_bar (line ~54);
> > 6. run_window_scroll_functions;
> > 7. redisplay_window (line ~415).
> These either go through safe__call, or through run_hook_with_args. I
> think the latter group should be converted to call safe__call and its
> friends. And then you will have what I described: all those calls go
> through a single gate.
Maybe tomorrow!
--
Alan Mackenzie (Nuremberg, Germany).
- Re: Redisplay hook error backtraces, (continued)
- 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
- Re: Redisplay hook error backtraces, Eli Zaretskii, 2022/07/15
- Re: Redisplay hook error backtraces, Alan Mackenzie, 2022/07/15
- Re: Redisplay hook error backtraces, Eli Zaretskii, 2022/07/16
- Re: Redisplay hook error backtraces, Eli Zaretskii, 2022/07/14
- Re: Redisplay hook error backtraces,
Alan Mackenzie <=
- Re: Redisplay hook error backtraces, Eli Zaretskii, 2022/07/16
- Re: Redisplay hook error backtraces, Alan Mackenzie, 2022/07/16
Re: Redisplay hook error bactraces [Was: Fontification error backtrace], Stefan Monnier, 2022/07/13