bug#67196: M-: uses a wrong value of debug-on-error when it is nil.

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

> That's a very good idea.  It would need little more than a new C function
> which would bind that variable then call eval.  Maybe move
> eval-expression-debug-on-error into eval.c, too.

Side note: there's recently been several things pointing to the need to
add something like Common Lisp's `handler-bind`.

`handler-bind` would provide a superset of the features that your
new C function would provide.  E.g. we could do something like:

    (defmacro with-debug-on-error (&rest body)
      `(handler-bind ((error #'debugger))
         ,@body))

which would mean that any error signal not caught within BODY itself
would call the debugger (and contrary to `condition-case`, that call is
performed before unwinding the stack, so we'd get the behavior we
expect from the debugger).

> Sorry, I wasn't clear enough.  During those 10 hours, I was under the
> impression that debug-on-error was t, because M-: debug-on-error said so.
> It actually was nil.  That's why I submitted this bug report.

I feel for you.  Personally I had a similar experience at some point but
instead of looking at the value of the var, I actually signaled
an error.

Seeing how I was getting into the debugger, I assumed that
`debug-on-error` was properly set (I had set it manually, so I (thought
I) knew that it was set, which is why I didn't even look at the var, but
apparently that was within a recursive edit that had it let-bound or
something, which is why it was actually unset).

The change you propose wouldn't have helped me directly in that case,
tho I think it probably would have circumvented the problem because the
var presumably wouldn't have been let-bound in the first place :-)

It took me less than 10 hours to figure out one of my many unjustified
assumptions, luckily.


        Stefan