bug#24514: 24.5; [WIP][PATCH] Lispy backtraces

[Vasilij Schneidermann]

> This looks great! I love it.  And the patch looks very clean, too.

Thanks!  I've updated the patch after a bit more testing.  The extra
debug line happened because the search in debug.el did actually search
for a `debug' call, so `(search-forward "\  (debug")` would match a call
to `debug-foo` as well.  Assuming there will always be extra args, this
can be solved by appending a space to the search string.  In case this
is not true, I'll have to go for `re-search-forward` to handle a
`(debug)` as well.  The other problem was that there were extraneous
spaces at times, this can be handled by making the line that prepends an
argument with a space unconditional.

> But it scares me a bit.  Some tools do depend on e.g. trimming a
> backtrace after printing it.  Does edebug work with your patch, for
> example?

Yes, it does.  However, you're raising a good point here.  I would
expect such a change to neither break Emacs core nor any of the bundled
Emacs Lisp code.  Guarantees about popular external code are hard to
make, but communicating the change with the respective authors and
maintainers should do the trick.  What I've initially asked for is
whether there might be any good reason for *not* doing things this way.

I've grepped the 24.5 sources and most usage of `backtrace' appears to
be of diagnostic nature.  The only thing other than `debug.el`
manipulating them is `edebug-backtrace' which I've never heard of
before.  I'll take a better look at its sources for my next revision of
the patch.

> I'm not sure what the right way to transition is.  Maybe Emacs should
> let Lisp programs access the backtraces in a structured way, and then
> backtrace printing would only be a user-facing facility (programs
> wouldn't use the textual representation).

There is actually a way to do this, simply use `backtrace-frame' with an
increasing integer argument until it returns nil:

    (let ((frame t) ; dummy value to kick-start the loop
          (i 0))
      (while frame
        (setq frame (backtrace-frame i))
        (message "%S" frame)
        (setq i (1+ i))))

This feature is used in `ert.el` to save a backtrace and reconstruct it.
Perhaps all current users of `backtrace' that rely on its current
representation should be using `backtrace-frame' instead?