GNU bug report logs - #24514
24.5; [WIP][PATCH] Lispy backtraces

Previous Next

Full log

Message #32 received at 24514 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Vasilij Schneidermann <v.schneidermann <at> gmail.com>
Cc: 24514 <at> debbugs.gnu.org
Subject: Re: bug#24514: 24.5; [WIP][PATCH] Lispy backtraces
Date: 23 Sep 2016 18:47:59 -0000

In article <mailman.2864.1474586229.22741.bug-gnu-emacs <at> gnu.org> you wrote:
> [-- text/plain, encoding 7bit, charset: utf-8, 30 lines --]

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

I'm not sure I'm in favour of this change.  There is some tool in some
circumstances which prints the lines in the "before:" fashion
interspersed with internal forms from function which start off with "("
in column 0.  Having the distinction between lines starting with "(" and
lines starting with the function name is handy for telling them apart.

Sorry I can't be more specific about the circumstances this happens in,
but it happens relatively frequently.

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

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.