[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Redisplay hook error bactraces [Was: Fontification error backtrace]
From: |
Stefan Monnier |
Subject: |
Re: Redisplay hook error bactraces [Was: Fontification error backtrace] |
Date: |
Wed, 13 Jul 2022 16:45:12 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
> What you suggest would imply a _lot_ of coding to make it happen. Does
> there exist anywhere any support for copyging a specpdl, and somehow
> making a lisp object out of it? Why do you think that copying the
> specpdl would be less work or less risky than directly generating a
> backtrace, as the current code does?
I don't think it needs to be much coding.
Stashing the full specpdl would be more work, admittedly, but turning
the specpdl into a list via something like `backtrace-frames` is trivial
(we could even easily move `backtrace-frames` to C if we wanted to be
paranoid about running ELisp at that point).
> The advantage of directly generating the backtrace is that all the
> infrastructure is already there. We've got mapbacktrace which
> encapsulates the formats of the specpdl. And debug-early.el, whose two
> functions total 60 lines (including doc strings and comments) and don't
> use any other Lisp whatsoever.
That potentially runs a crapload of code via various hooks, many of
which can be influenced by variables dynamically bound in the context of
the error.
Moving the bulk of the work to a normal context means we can be much
more relaxed about using "fully featured" code, so there'll be much less
resistance to over-engineering :-)
Stefan
Re: Redisplay hook error bactraces [Was: Fontification error backtrace], Stefan Monnier, 2022/07/13