[Top][All Lists]

[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 12:10:13 +0300

> Date: Thu, 14 Jul 2022 09:01:16 +0000
> Cc: larsi@gnus.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> > You want to distinguish errors inside condition-case?
> More, distinguish the different condition-cases in which errors might
> occur.

What else is exposed to Lisp?  We are talking about catching Lisp
errors only, right?

> > > > Can we discuss how to implement it without introducing a special
> > > > handler and without adding new safe_run_hooks_* functions?
> I think we need the new function safe_run_hooks_2_with_backtrace (see
> below), since there is currently no "safe" function for hooks with two
> arguments.  But some of the other ones could disappear (see below).

What is the second argument, and why do we need it?

> OK, I have an idea.  I restore the variable redisplay_lisping back into
> the code (I took it out last night), binding it to true (or Qt?) at every
> place in xdisp.c where redisplay calls a Lisp hook.

These all go through a single function, so there's just one place to
do that.

> I then test that variable in internal_condition_case_n in place of
> having the extra bool argument to that function.
> That would then get rid of the new functions
> safe_run_hooks_with_backtrace_funcall and safe_run_hooks_with_backtrace.
> We could also rename safe_run_hooks_2_with_backtrace by removing
> "_with_backtrace" from the name.
> What do you think?

Sounds good, but let's see the code.

And I still would like you to explore Stefan's suggestion, since doing
too much non-trivial Lisp stuff in signal_or_quit is better avoided.


reply via email to

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