Re: Why is it so difficult to get a Lisp backtrace?

[Alan Mackenzie]

Hello, Lars.

On Sat, Jun 25, 2022 at 17:35:02 +0200, Lars Ingebrigtsen wrote:
> Alan Mackenzie <acm@muc.de> writes:

> >> This third group of users is poorly catered for by the current
> >> collection of mechanisms.  See also bug #56201, with thanks to
> >> Andreas and Lars who helped me get to the bottom of it.  To be
> >> reasonably sure of getting a backtrace, it seems one needs to do
> >> all of the following:
> >> (i) (setq debug-on-error t).
> >> (ii) (setq debug-on-signal t).
> >> (iii) Bind debug-ignored-errors to nil.
> >> (iv) Pray.

> You probably also need to ensure that inhibit-redisplay is nil at the
> point of the error, I think?  (At least I vaguely recall having to
> remove some of those bindings to get a backtrace...)

For example, by testing a flag in the backtrace function, and binding
inhibit-redisplay to nil if that flag is set.  This could get quite
complicate quite quickly.

Another thing I'd like to be able to do is get a backtrace when there's
an error in font-locking during redisplay.  That's a whole order of
magnitude difference in complexity.

> > I mean something like the following, which to a first approximation,
> > works.  To use it, do M-x debug-next-command and the execute the
> > command expected to give errors:

> I like it, but it may not be useful in all contexts -- errors are used
> as a programming mechanism here and there (i.e., throwing an error
> symbol to be caught by the caller), and you'll get backtraces from
> these non-error errors, too, unfortunately.

As I suggested in my reply to Stefan, maybe a C-u argument to the
function could be used to exclude (or include) debug-on-signal from the
mix.  Or something like that.

> -- 
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no

-- 
Alan Mackenzie (Nuremberg, Germany).