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

[Clément Pit--Claudel]

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

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?

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

Cheers,
Clément.

On 2016-09-22 19:14, Vasilij Schneidermann wrote:
> I wrote a minimal patch that increases the overall consistency in a
> backtrace buffer by printing the call stack frames as S-Expressions.
> 
> Before:
> 
> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p t)
>   +(1 t)
>   eval((+ 1 t) nil)
>   eval-expression((+ 1 t) nil)
>   call-interactively(eval-expression nil nil)
>   command-execute(eval-expression)
> 
> After:
> 
> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p t)
>   (debug error (wrong-type-argument number-or-marker-p t))
>   (+ 1 t)
>   (eval (+ 1 t) nil)
>   (eval-expression (+ 1 t) nil)
>   (funcall-interactively eval-expression (+ 1 t) nil)
>   (call-interactively eval-expression nil nil)
>   (command-execute eval-expression)
> 
> Now, this patch isn't perfect.  For some reason there's an extra debug
> line in the second version, I've yet to investigate into the reason for
> this.  The other problem is that while I can't imagine any reason to go
> back to the original view of the backtrace, I cannot rule out that this
> change might break other tools relying on it.  I'd appreciate any
> feedback on this.
>

signature.asc
Description: OpenPGP digital signature