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

[Eli Zaretskii]

> Date: Sat, 25 Nov 2023 10:32:23 +0000
> Cc: monnier@iro.umontreal.ca, 67196@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > 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.

What I had in mind was a function exposed to Lisp that would set an
internal variable not exposed to Lisp.

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

So maybe instead of changing how this stuff works we should improve
how debug-on-error's value is reported by M-: and other eval commands?

Note that (AFAIU) your change doesn't just solve the problem you
bumped into, it also changes the value of debug-on-error inside
eval-expression etc., when eval-expression-debug-on-error's value is
non-nil, but not t.  I wonder what is the reason for that?