backtrace-mode

[Gemini Lasswell <gazally@runbox.com>]

Hello all,

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

Questions:

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


Gemini