emacs-devel
[Top][All Lists]
Advanced

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]