bug#15101: 24.3.50; debugger-eval-expression broken

[Helmut Eller <eller.helmut@gmail.com>]

On Fri, Aug 16 2013, Stefan Monnier wrote:

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

In this example, there are two positions of interest:

  1. for the newest stack frame, the one that looks like foo(0), the
     "instruction pointer" would be at the callsite for debug.

  2. for all other stack frames of the form foo(X) the instruction
     pointer would be at the same location: the (recursive) callsite for
     foo.

Are there any other places that foo(X) could possibly denote? I think
not.  So, what value has n at position 1?

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

The 1+ doesn't solve/change that problem, does it?

Helmut