emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Redisplay hook error backtraces


From: Eli Zaretskii
Subject: Re: Redisplay hook error backtraces
Date: Thu, 14 Jul 2022 20:09:02 +0300

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



reply via email to

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