GNU bug report logs - #15101
24.3.50; debugger-eval-expression broken

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: 15101 <at> debbugs.gnu.org
Subject: bug#15101: 24.3.50; debugger-eval-expression broken
Date: Fri, 16 Aug 2013 12:14:23 -0400

> If we go to the line "foo(10)" I would expect that n is 10. With your
> definition n is 11. I would argue that your version is confusing.

I think the problem comes from the fact that contrary to traditional
debuggers, we don't have the "line-number info".

In a traditional debugger, you'd have "foo(10) at foo.el:25", pointing
out exactly where you are inside `foo'.  Whereas in Elisp backtraces you
only have "the expression that was being evaluated", so "foo(10)"
doesn't tell you where you were inside `foo', instead it tells you that
you were somewhere where a call to `(foo 10) was made.

> Can you give an example of what would be weird with this change:
[...]
> -                    (condition-case nil (1+ (debugger-frame-number 'skip-base))
> +                    (condition-case nil (debugger-frame-number 'skip-base)

I started with this, but found it very weird for example with things like

   (let ((x (toto)) (y (titi))) (tata))

where you'd naturally expect to be able to find the value of `x' or `y',
but that's only true if the debugger was called from `tata'.  If instead
the debugger was called from within `toto' or `titi', `x' and `y' aren't
bound yet.


        Stefan

Previous Next

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