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

[Stefan Monnier]

> 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