[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tue, 19 Jun 2018 15:58:44 -0700
mu4e 0.9.18; emacs 26.1.50
Elisp backtraces are printed in 3 places (subr.el, edebug.el and
debug.el) and displayed in buffers in 3 places (debug.el, edebug.el
and ert.el) without much shared code. I wanted to improve Edebug's
backtraces, and then to make the same things work in ERT and the
debugger without writing it all 3 times, which got me started writing
a backtrace library.
I've just pushed a new branch scratch/backtrace-mode, containing a new
file backtrace.el with the shared backtrace code and a new
backtrace-mode with better backtrace viewing, along with changes to
ERT, Edebug and the debugger to make them all use it, and supporting
changes in cl-print.el.
This code is a Work In Progress, still liberally sprinkled with TODOs.
But it works and can do nifty stuff like pretty-print backtrace frames
and expand "..."s, so please give it a try and let me know what you
think. (It's my first major mode and my first time doing anything
with text properties, so there might be some beginner mistakes.)
- debugger-stack-frame-as-list now seems like it should be in
backtrace mode's defcustoms instead of the debugger's. Should it be
moved or left where it is?
- Should I move the backtrace related functions from subr.el to
backtrace.el? There's a function in backtrace.el currently called
backtrace-backtrace which could replace subr's backtrace.
- I haven't made a menu yet, but I assume backtrace-mode should have
one. Should I use easy-menu-define for that, and why doesn't
debug.el use easy-menu-define?
- When you enter the debugger, or when you ask ERT to show a
backtrace, both of them pop to the backtrace buffer. But when you
ask Edebug to show a backtrace, it just shows the backtrace buffer.
I think all three should do the same thing. Now that Edebug's
backtrace has commands other than quit, I think it should also be
popped to. Any objections?
- Now that xref-find-definitions works in backtrace buffers, I think
it would be better to stop making buttons for the functions in a
backtrace, and to document M-. as the best way to jump to function
definitions from backtraces. What do you think of this change to
existing behavior, with or without a new customization variable to
preserve the old behavior?
- backtrace--print-to-string (which tries to find values of
print-length and print-level to fit the printed representation of an
object into a specified number of characters) and ellipsis expansion
would also be useful for ERT, edebug and debug results printing. If
that happens, a way to expand ellipses in *Messages* would be
nice. So maybe these features don't belong in backtrace.el,
but I don't know where they do belong.
- Tab and backtab are used by button navigation. Seems to me the next
best choice for bindings for pretty printing and collapsing back to
one line are '+' and '-' except '-' is bound to negative-argument
in special-mode. So I'm currently using '+' and '=', but I don't
like the '='. Would it be ok to rebind '-' in backtrace buffers?
Bugs fixed in this branch:
- 18609, fontification in backtraces
- 18558, debugger slow with long strings
- 15749, *Backtrace* loses text scaling
- 1428, links in Edebug backtraces
On my todo list:
- bug#14081, add a link to "reading at buffer pos ..."
- A new command for Edebug backtraces only, 's' to jump to the source
code for the frame at point. I'm planning on adding an indicator in
the left margin (where the regular debugger puts its *) to show
whether the source is available for a given frame, since the frames
in a backtrace might be a mix of code instrumented and not
instrumented by Edebug.