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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Sat, Nov 25, 2023 at 09:59:45 +0200, Eli Zaretskii wrote:
> > Date: Fri, 24 Nov 2023 22:21:27 +0000
> > Cc: Eli Zaretskii <eliz@gnu.org>, 67196@debbugs.gnu.org, acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

> > > So you kicked the can a bit further down the road.
> > > The next bug report will be that `M-: debug-from--eval-expression` does
> > > not return the expected value.

> > Not at all.  debug-from--eval-expression is a purely internal variable,
> > unlike debug-on-error which is intended for user use.  It is bound in
> > exactly one place, and tested in exactly one place.

> > Anybody reporting such a "bug" would legitimately get the reply "not a
> > bug".

> How about not exposing the internal variable to Lisp at all?

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.

> > For what it's worth, I lost about 10 hours of time trying to debug
> > a situation where I wasn't getting a backtrace, despite debug-on-error
> > being t.  The problem was that d-o-e wasn't t at all, it was nil.  M-:
> > had been lying.  

> You never described that situation, AFAICT.  I think you should, so
> that we could assess how grave the problem is, which is an important
> part of deciding whether the solution you propose is useful.  I don't
> understand how could you NOT get a backtrace when debug-on-error is
> non-nil.

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.

-- 
Alan Mackenzie (Nuremberg, Germany).