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

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

[Alan Mackenzie]

Hello, Emacs.

On the master branch (and probably any recent Emacs):

(i) emacs -Q
(ii) C-h v debug-on-error RET
(iii) M-: debug-on-error RET

From (ii) it will be seen that debug-on-error's value is nil.
(iii) wrongly reports that its value is t.  This is a bug.

#########################################################################

What is happening here is that eval-expression binds debug-on-error to
an uninterned symbol called "t", so that d-o-e will be set to non-nil
for the evaluation of the coming form.

This has the unwanted side effect of ignoring the actual value of d-o-e
in forms which use it.  For example, if the variable is set to a list of
error symbols, this value gets ignored on evaluating a form with M-:.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Wed, 15 Nov 2023 13:48:40 +0000
> From: Alan Mackenzie <acm@muc.de>
> 
> Hello, Emacs.
> 
> On the master branch (and probably any recent Emacs):
> 
> (i) emacs -Q
> (ii) C-h v debug-on-error RET
> (iii) M-: debug-on-error RET
> 
> >From (ii) it will be seen that debug-on-error's value is nil.
> (iii) wrongly reports that its value is t.  This is a bug.
> 
> #########################################################################
> 
> What is happening here is that eval-expression binds debug-on-error to
> an uninterned symbol called "t", so that d-o-e will be set to non-nil
> for the evaluation of the coming form.
> 
> This has the unwanted side effect of ignoring the actual value of d-o-e
> in forms which use it.  For example, if the variable is set to a list of
> error symbols, this value gets ignored on evaluating a form with M-:.

Aren't we doing this on purpose, Stefan?

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

[Alan Mackenzie]

Hello, Eli.

On Wed, Nov 15, 2023 at 19:19:17 +0200, Eli Zaretskii wrote:
> > Date: Wed, 15 Nov 2023 13:48:40 +0000
> > From: Alan Mackenzie <acm@muc.de>

> > Hello, Emacs.

> > On the master branch (and probably any recent Emacs):

> > (i) emacs -Q
> > (ii) C-h v debug-on-error RET
> > (iii) M-: debug-on-error RET

> > >From (ii) it will be seen that debug-on-error's value is nil.
> > (iii) wrongly reports that its value is t.  This is a bug.

> > #########################################################################

> > What is happening here is that eval-expression binds debug-on-error to
> > an uninterned symbol called "t", so that d-o-e will be set to non-nil
> > for the evaluation of the coming form.

> > This has the unwanted side effect of ignoring the actual value of d-o-e
> > in forms which use it.  For example, if the variable is set to a list of
> > error symbols, this value gets ignored on evaluating a form with M-:.

> Aren't we doing this on purpose, Stefan?

Thinking about it more clearly, we're using one variable, debug-on-error,
for two conflicting purposes:
(i) The calling mechanism of execute-extended-command, including the
  invocation of the debugger, should an error be signalled.
(ii) Use in the form to be evaluated, where the variable's value outside
  of execute-extended-command should endure.

It would seem to me we really need two distinct variables for these two
purposes.  I think it's clear that purpose (ii) would be the one to
retain use of debug-on-error.

-- 
Alan Mackenzie (Nuremberg, Germany).

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]

> Thinking about it more clearly, we're using one variable, debug-on-error,
> for two conflicting purposes:
> (i) The calling mechanism of execute-extended-command, including the
>   invocation of the debugger, should an error be signalled.
> (ii) Use in the form to be evaluated, where the variable's value outside
>   of execute-extended-command should endure.

Yes, there's a conflicting need here: we want to control the way `eval`
works "from the outside", i.e. we want the `debug-on-error` to apply to
the evaluator but not to the code being evaluated.

But `eval` doesn't distinguish between the context of the evaluator and
the context of the code being evaluated because all ELisp code uses the
same evaluator.  I can't think of any way to split the variable into two
to solve the problem.  Instead it gives me the impression we're trying
some impossible feat like watching oneself sleep.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  67196@debbugs.gnu.org
> Date: Sun, 19 Nov 2023 12:19:49 -0500
> 
> it gives me the impression we're trying some impossible feat like
> watching oneself sleep.

This is Emacs: the impossible we do today; miracles take a little
longer.

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]

Eli wrote:
> This is Emacs: the impossible we do today; miracles take
> a little longer.

To which dick wrote:
> I assure you your smug self-satisfaction is shared only by the
> unemployable programmers you compare yourself to.

Thank you Dick for the subtle comic relief.


        Stefan

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

[Alan Mackenzie]

Hello, Stefan.

On Sun, Nov 19, 2023 at 12:19:49 -0500, Stefan Monnier wrote:
> > Thinking about it more clearly, we're using one variable, debug-on-error,
> > for two conflicting purposes:
> > (i) The calling mechanism of execute-extended-command, including the
> >   invocation of the debugger, should an error be signalled.
> > (ii) Use in the form to be evaluated, where the variable's value outside
> >   of execute-extended-command should endure.

> Yes, there's a conflicting need here: we want to control the way `eval`
> works "from the outside", i.e. we want the `debug-on-error` to apply to
> the evaluator but not to the code being evaluated.

> But `eval` doesn't distinguish between the context of the evaluator and
> the context of the code being evaluated because all ELisp code uses the
> same evaluator.  I can't think of any way to split the variable into two
> to solve the problem.  Instead it gives me the impression we're trying
> some impossible feat like watching oneself sleep.

I can think of a way to do this (indeed, I've got a trial implementation
here which works).

Firstly, though, there is a bug in the doc string of
eval-expression-debug-on-error: rather than stating what the meaning of
the variable is, what it's for, it states the low level details of how
it achieves the desired effect.  This is needlessly restrictive.  I
propose changing that doc string from:

    If non-nil set `debug-on-error' to t in `eval-expression'.
    If nil, don't change the value of `debug-on-error'.

to something like:

    Non-nil means enter debugger on an error in a call from `eval-expression'.
    Does not apply to errors handled by `condition-case' or those
    matched by `debug-ignored-errors'.
    A nil value for this variable will not prevent an entry to
    the debugger caused by other variables such as `debug-on-error'.
    Like `debug-on-error', this variable's value can also be a list,
    with the same meaning as for `debug-on-error'.    

..  With this change, the mechanism for eval-expression-debug-on-error
can be changed such that it doesn't become confused with debug-on-error.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Fri, 24 Nov 2023 17:10:47 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, 67196@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> Firstly, though, there is a bug in the doc string of
> eval-expression-debug-on-error: rather than stating what the meaning of
> the variable is, what it's for, it states the low level details of how
> it achieves the desired effect.  This is needlessly restrictive.  I
> propose changing that doc string from:
> 
>     If non-nil set `debug-on-error' to t in `eval-expression'.
>     If nil, don't change the value of `debug-on-error'.
> 
> to something like:
> 
>     Non-nil means enter debugger on an error in a call from `eval-expression'.
>     Does not apply to errors handled by `condition-case' or those
>     matched by `debug-ignored-errors'.
>     A nil value for this variable will not prevent an entry to
>     the debugger caused by other variables such as `debug-on-error'.

First, the last two sentences above should be transposed, as the
second one is not related to the 1st one, but the 3rd one is.

And second, please try to reword so that the text is less complicated
and easier to understand.

Thanks.

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]

> I can think of a way to do this (indeed, I've got a trial implementation
> here which works).

Eager to see it,


        Stefan

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

[Alan Mackenzie]

Hello, Eli and Stefan.

On Fri, Nov 24, 2023 at 20:48:40 +0200, Eli Zaretskii wrote:
> > Date: Fri, 24 Nov 2023 17:10:47 +0000
> > Cc: Eli Zaretskii <eliz@gnu.org>, 67196@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > Firstly, though, there is a bug in the doc string of
> > eval-expression-debug-on-error: rather than stating what the meaning of
> > the variable is, what it's for, it states the low level details of how
> > it achieves the desired effect.  This is needlessly restrictive.  I
> > propose changing that doc string from:

> >     If non-nil set `debug-on-error' to t in `eval-expression'.
> >     If nil, don't change the value of `debug-on-error'.

> > to something like:

> >     Non-nil means enter debugger on an error in a call from `eval-expression'.
> >     Does not apply to errors handled by `condition-case' or those
> >     matched by `debug-ignored-errors'.
> >     A nil value for this variable will not prevent an entry to
> >     the debugger caused by other variables such as `debug-on-error'.

> First, the last two sentences above should be transposed, as the
> second one is not related to the 1st one, but the 3rd one is.

Done.

> And second, please try to reword so that the text is less complicated
> and easier to understand.

I'm perhaps a bit too close to it.  Apart from the first line (for which
too much information needs squashing in), I can't really see much scope
for improvement.

> Thanks.

Anyway, here's the patch of the current state.  With it, M-:
debug-on-error RET shows nil, when that is the case.  M-: (foo) enters
the debugger when an error gets signalled, assuming
eval-expression-debug-on-error is t (or a suitable list), but doesn't
enter the debugger when e-e-d-o-error is nil.

There's a slight disadvantage to the approach, namely the introduction of
a new internal variable debug-from--eval-expression which is tested from
signal_or_quit.  On the other hand, eval-expression itself has been
noticeably simplified.



diff --git a/lisp/simple.el b/lisp/simple.el
index 02c68912dba..e8a9a795c0b 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -1981,11 +1981,17 @@ eval-expression-print-length
   :version "21.1")
 
 (defcustom eval-expression-debug-on-error t
-  "If non-nil set `debug-on-error' to t in `eval-expression'.
-If nil, don't change the value of `debug-on-error'."
+  "Non-nil means enter debugger on error on a call from `eval-expression'.
+Does not apply to errors handled by `condition-case' or those
+matched by `debug-ignored-errors'.
+Like `debug-on-error', this variable's value can also be a list,
+with the same meaning as for `debug-on-error'.
+
+A nil value for this variable will not prevent an entry to
+the debugger caused by other variables such as `debug-on-error'."
   :group 'lisp
   :type 'boolean
-  :version "21.1")
+  :version "30.1")
 
 (defcustom eval-expression-print-maximum-character 127
   "The largest integer that will be displayed as a character.
@@ -2120,34 +2126,19 @@ eval-expression
    (cons (read--expression "Eval: ")
          (eval-expression-get-print-arguments current-prefix-arg)))
 
-  (let (result)
-    (if (null eval-expression-debug-on-error)
-        (setq result
-              (values--store-value
-               (eval (let ((lexical-binding t)) (macroexpand-all exp)) t)))
-      (let ((old-value (make-symbol "t")) new-value)
-        ;; Bind debug-on-error to something unique so that we can
-        ;; detect when evalled code changes it.
-        (let ((debug-on-error old-value))
-          (setq result
-	        (values--store-value
-                 (eval (let ((lexical-binding t)) (macroexpand-all exp)) t)))
-	  (setq new-value debug-on-error))
-        ;; If evalled code has changed the value of debug-on-error,
-        ;; propagate that change to the global binding.
-        (unless (eq old-value new-value)
-	  (setq debug-on-error new-value))))
-
-    (let ((print-length (unless no-truncate eval-expression-print-length))
-          (print-level  (unless no-truncate eval-expression-print-level))
-          (eval-expression-print-maximum-character char-print-limit)
-          (deactivate-mark))
-      (let ((out (if insert-value (current-buffer) t)))
-        (prog1
-            (prin1 result out)
-          (let ((str (and char-print-limit
-                          (eval-expression-print-format result))))
-            (when str (princ str out))))))))
+  (let* ((debug-from--eval-expression eval-expression-debug-on-error)
+         (result (values--store-value
+                  (eval (let ((lexical-binding t)) (macroexpand-all exp)) t)))
+         (print-length (unless no-truncate eval-expression-print-length))
+         (print-level  (unless no-truncate eval-expression-print-level))
+         (eval-expression-print-maximum-character char-print-limit)
+         (deactivate-mark)
+         (out (if insert-value (current-buffer) t)))
+    (prog1
+        (prin1 result out)
+      (let ((str (and char-print-limit
+                      (eval-expression-print-format result))))
+        (when str (princ str out))))))
 
 (defun edit-and-eval-command (prompt command)
   "Prompting with PROMPT, let user edit COMMAND and eval result.
diff --git a/src/eval.c b/src/eval.c
index 12e811ce264..6cadda01efb 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -2033,7 +2033,8 @@ maybe_call_debugger (Lisp_Object conditions, Lisp_Object sig, Lisp_Object data)
       /* Does user want to enter debugger for this kind of error?  */
       && (signal_quit_p (sig)
 	  ? debug_on_quit
-	  : wants_debugger (Vdebug_on_error, conditions))
+	  : (wants_debugger (Vdebug_from__eval_expression, conditions)
+	     || wants_debugger (Vdebug_on_error, conditions)))
       && ! skip_debugger (conditions, combined_data)
       /* See commentary on definition of
          `internal-when-entered-debugger'.  */
@@ -4299,6 +4300,13 @@ syms_of_eval (void)
 See also the variable `debug-on-quit' and `inhibit-debugger'.  */);
   Vdebug_on_error = Qnil;
 
+  DEFVAR_LISP ("debug-from--eval-expression", Vdebug_from__eval_expression,
+	       doc: /* Non-nil means enter debugger if an error is signaled.
+This only applies in forms called by `eval-expression'.  This variable
+has the same semantics as `debug-on-error'.  It is an internal variable
+only.  */);
+  Vdebug_from__eval_expression = Qnil;
+
   DEFVAR_LISP ("debug-ignored-errors", Vdebug_ignored_errors,
     doc: /* List of errors for which the debugger should not be called.
 Each element may be a condition-name or a regexp that matches error messages.


-- 
Alan Mackenzie (Nuremberg, Germany).

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]

> +  (let* ((debug-from--eval-expression eval-expression-debug-on-error)
> +         (result (values--store-value
> +                  (eval (let ((lexical-binding t)) (macroexpand-all exp)) t)))
> +         (print-length (unless no-truncate eval-expression-print-length))
> +         (print-level  (unless no-truncate eval-expression-print-level))
> +         (eval-expression-print-maximum-character char-print-limit)
> +         (deactivate-mark)
> +         (out (if insert-value (current-buffer) t)))
> +    (prog1
> +        (prin1 result out)
> +      (let ((str (and char-print-limit
> +                      (eval-expression-print-format result))))
> +        (when str (princ str out))))))

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.

FWIW, the other way I came up to circumvent the problem is to test the
shape of the expression to evaluate and only use
`eval-expression-debug-on-error` when the expression is not a mere
symbol (for which the backtrace would presumably not be interesting anyway).
But then we get the weird situation where `M-x debug-on-error` can
return nil but `M-x (list debug-on-error ...)` returns a list that
starts with t.

I think I'd rather keep the current code, whose semantics is
actually simpler.


        Stefan

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

[Alan Mackenzie]

Hello, Stefan.

On Fri, Nov 24, 2023 at 16:25:11 -0500, Stefan Monnier wrote:
> > +  (let* ((debug-from--eval-expression eval-expression-debug-on-error)
> > +         (result (values--store-value
> > +                  (eval (let ((lexical-binding t)) (macroexpand-all exp)) t)))
> > +         (print-length (unless no-truncate eval-expression-print-length))
> > +         (print-level  (unless no-truncate eval-expression-print-level))
> > +         (eval-expression-print-maximum-character char-print-limit)
> > +         (deactivate-mark)
> > +         (out (if insert-value (current-buffer) t)))
> > +    (prog1
> > +        (prin1 result out)
> > +      (let ((str (and char-print-limit
> > +                      (eval-expression-print-format result))))
> > +        (when str (princ str out))))))

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

> FWIW, the other way I came up to circumvent the problem is to test the
> shape of the expression to evaluate and only use
> `eval-expression-debug-on-error` when the expression is not a mere
> symbol (for which the backtrace would presumably not be interesting anyway).
> But then we get the weird situation where `M-x debug-on-error` can
> return nil but `M-x (list debug-on-error ...)` returns a list that
> starts with t.

[ By M-x, I assume you're meaning M-:.]

Yes.  Such a patch wouldn't fix the bug.  The root of the bug is trying
to make debug-on-error do two different contradictory jobs, as we've
already discussed.  To fix this, you've either got to decide not to do
one of these jobs at all, or introduce a new variable.  My patch does
the second of these.

> I think I'd rather keep the current code, whose semantics is
> actually simpler.

No.  My patch fixes the bug, by introducing a separate variable to do
one of the two jobs that debug-on-error is currently trying to do.  This
is a simplification.  As a side effect, eval-expression has been reduced
from 59 to 44 lines; not counting the doc string this is a reduction of
around 50%.

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.  

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Fri, 24 Nov 2023 20:54:45 +0000
> Cc: 67196@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> > >     Non-nil means enter debugger on an error in a call from `eval-expression'.
> > >     Does not apply to errors handled by `condition-case' or those
> > >     matched by `debug-ignored-errors'.
> > >     A nil value for this variable will not prevent an entry to
> > >     the debugger caused by other variables such as `debug-on-error'.
> 
> > First, the last two sentences above should be transposed, as the
> > second one is not related to the 1st one, but the 3rd one is.
> 
> Done.
> 
> > And second, please try to reword so that the text is less complicated
> > and easier to understand.
> 
> I'm perhaps a bit too close to it.  Apart from the first line (for which
> too much information needs squashing in), I can't really see much scope
> for improvement.

Here:

   (defcustom eval-expression-debug-on-error t
    "If non-nil, enter debugger if `eval-expression' signals an error.
  A non-nil value means set `debug-on-error' to that value when calling
  `eval-expression'; this will enter a debugger if `eval-expression'
  signals an error.  A nil value means don't change the value of
  `debug-on-error' when calling `eval-expression'.
  The value can also be a list, with the same meaning as for `debug-on-error'.
  Like  `debug-on-error', this variable does not apply to errors handled
  by `condition-case' or those matched by `debug-ignored-errors'."

> +  DEFVAR_LISP ("debug-from--eval-expression", Vdebug_from__eval_expression,
> +	       doc: /* Non-nil means enter debugger if an error is signaled.
> +This only applies in forms called by `eval-expression'.  This variable
> +has the same semantics as `debug-on-error'.  It is an internal variable
> +only.  */);

The doc string should be just

  /* Internal use only, used by `eval-expression'.  */

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

[Eli Zaretskii]

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

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

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

[Alan Mackenzie]

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

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?

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

[Alan Mackenzie]

Hello, Eli.

On Sat, Nov 25, 2023 at 13:15:15 +0200, Eli Zaretskii wrote:
> > 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.

The would still require an unwind-protect somewhere.  I've implemented
sub-eval-expression in eval.c.  debug-from--eval-expression is no longer
visible from Lisp.  Perhaps this is good enough.  

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

Yes, but that might be complicated, and won't help the user trying to
debug something which depends on debug-on-error, who is using M-: to try
to test it.  I still say the bug is trying to make debug-on-error do too
much, more than it's capable of.

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

I don't see that in my current version of the patch (below).  To test
this, I used the following:

(defun foo ()
  (interactive)
  (message "debug-on-error is %s" debug-on-error)
  (message "eval-expression-debug-on-error is %s" eval-expression-debug-on-error)
  (car 'foo))

, and called it with various settings of debug-on-error and
eval-expression-debug-on-error.  In particular, with

  (setq eval-expression-debug-on-error '(wrong-type-argument))

, I still see debug-on-error reported as nil.



diff --git a/lisp/cus-start.el b/lisp/cus-start.el
index 6d83aaf4d14..9d176c6c599 100644
--- a/lisp/cus-start.el
+++ b/lisp/cus-start.el
@@ -262,6 +262,13 @@ minibuffer-prompt-properties--setter
 					     :value (nil)
 					     (symbol :format "%v"))
 				     (const :tag "always" t)))
+             (eval-expression-debug-on-error debug
+                                             (choice (const :tag "off")
+                                                     (repeat :menu-tag "When"
+                                                             :value (nil)
+                                                             (symbol :format "%v"))
+                                                     (const :tag "always" t))
+                                             "30.1")
 	     (debug-ignored-errors debug (repeat (choice symbol regexp)))
 	     (debug-on-quit debug boolean)
 	     (debug-on-signal debug boolean)
diff --git a/lisp/simple.el b/lisp/simple.el
index 02c68912dba..f4c9873ceed 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -1980,13 +1980,6 @@ eval-expression-print-length
   :type '(choice (const :tag "No Limit" nil) integer)
   :version "21.1")
 
-(defcustom eval-expression-debug-on-error t
-  "If non-nil set `debug-on-error' to t in `eval-expression'.
-If nil, don't change the value of `debug-on-error'."
-  :group 'lisp
-  :type 'boolean
-  :version "21.1")
-
 (defcustom eval-expression-print-maximum-character 127
   "The largest integer that will be displayed as a character.
 This affects printing by `eval-expression' (via
@@ -2120,34 +2113,18 @@ eval-expression
    (cons (read--expression "Eval: ")
          (eval-expression-get-print-arguments current-prefix-arg)))
 
-  (let (result)
-    (if (null eval-expression-debug-on-error)
-        (setq result
-              (values--store-value
-               (eval (let ((lexical-binding t)) (macroexpand-all exp)) t)))
-      (let ((old-value (make-symbol "t")) new-value)
-        ;; Bind debug-on-error to something unique so that we can
-        ;; detect when evalled code changes it.
-        (let ((debug-on-error old-value))
-          (setq result
-	        (values--store-value
-                 (eval (let ((lexical-binding t)) (macroexpand-all exp)) t)))
-	  (setq new-value debug-on-error))
-        ;; If evalled code has changed the value of debug-on-error,
-        ;; propagate that change to the global binding.
-        (unless (eq old-value new-value)
-	  (setq debug-on-error new-value))))
-
-    (let ((print-length (unless no-truncate eval-expression-print-length))
-          (print-level  (unless no-truncate eval-expression-print-level))
-          (eval-expression-print-maximum-character char-print-limit)
-          (deactivate-mark))
-      (let ((out (if insert-value (current-buffer) t)))
-        (prog1
-            (prin1 result out)
-          (let ((str (and char-print-limit
-                          (eval-expression-print-format result))))
-            (when str (princ str out))))))))
+  (let* ((result (values--store-value
+                  (sub-eval-expression (macroexpand-all exp))))
+         (print-length (unless no-truncate eval-expression-print-length))
+         (print-level  (unless no-truncate eval-expression-print-level))
+         (eval-expression-print-maximum-character char-print-limit)
+         (deactivate-mark)
+         (out (if insert-value (current-buffer) t)))
+    (prog1
+        (prin1 result out)
+      (let ((str (and char-print-limit
+                      (eval-expression-print-format result))))
+        (when str (princ str out))))))
 
 (defun edit-and-eval-command (prompt command)
   "Prompting with PROMPT, let user edit COMMAND and eval result.
diff --git a/src/eval.c b/src/eval.c
index 12e811ce264..eccabf3a091 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -2033,7 +2033,8 @@ maybe_call_debugger (Lisp_Object conditions, Lisp_Object sig, Lisp_Object data)
       /* Does user want to enter debugger for this kind of error?  */
       && (signal_quit_p (sig)
 	  ? debug_on_quit
-	  : wants_debugger (Vdebug_on_error, conditions))
+	  : (wants_debugger (Vdebug_from__eval_expression, conditions)
+	     || wants_debugger (Vdebug_on_error, conditions)))
       && ! skip_debugger (conditions, combined_data)
       /* See commentary on definition of
          `internal-when-entered-debugger'.  */
@@ -2383,6 +2384,19 @@ DEFUN ("eval", Feval, Seval, 1, 2, 0,
   return unbind_to (count, eval_sub (form));
 }
 
+DEFUN ("sub-eval-expression", Fsub_eval_expression, Ssub_eval_expression,
+       1, 1, 0,
+       doc: /* Evaluate FORM and return its value.
+This function should be called only from `eval-expression'.
+It evaluates with `lexical-binding' non-nil, and handles
+`eval-expression-debug-on-error'.  */)
+  (Lisp_Object form)
+{
+  specpdl_ref count = SPECPDL_INDEX ();
+  specbind (Qdebug_from__eval_expression, Veval_expression_debug_on_error);
+  return unbind_to (count, Feval (form, Qt));
+}
+
 void
 grow_specpdl_allocation (void)
 {
@@ -4299,6 +4313,29 @@ syms_of_eval (void)
 See also the variable `debug-on-quit' and `inhibit-debugger'.  */);
   Vdebug_on_error = Qnil;
 
+  DEFSYM (Qeval_expression_debug_on_error, "eval-expression-debug-on-error");
+  DEFVAR_LISP ("eval-expression-debug-on-error",
+	       Veval_expression_debug_on_error,
+	       doc: /* Non-nil means enter debugger on error on a call from `eval-expression'.
+Does not apply to errors handled by `condition-case' or those
+matched by `debug-ignored-errors'.
+Like `debug-on-error', this variable's value can also be a list,
+with the same meaning as for `debug-on-error'.
+
+A nil value for this variable will not prevent an entry to
+the debugger caused by other variables such as `debug-on-error'.  */);
+  Veval_expression_debug_on_error = Qt;
+
+  DEFSYM (Qdebug_from__eval_expression, "debug-from--eval-expression");
+  DEFVAR_LISP ("debug-from--eval-expression", Vdebug_from__eval_expression,
+	       doc: /* Non-nil means enter debugger if an error is signaled.
+This only applies in forms called by `eval-expression'.  This variable
+has the same semantics as `debug-on-error'.  It is an internal variable
+only.  */);
+  Vdebug_from__eval_expression = Qnil;
+  /* debug-from--eval-expression should not be visible from Lisp.  */
+  Funintern (Qdebug_from__eval_expression, Qnil);
+
   DEFVAR_LISP ("debug-ignored-errors", Vdebug_ignored_errors,
     doc: /* List of errors for which the debugger should not be called.
 Each element may be a condition-name or a regexp that matches error messages.
@@ -4455,6 +4492,7 @@ syms_of_eval (void)
   defsubr (&Sautoload);
   defsubr (&Sautoload_do_load);
   defsubr (&Seval);
+  defsubr (&Ssub_eval_expression);
   defsubr (&Sapply);
   defsubr (&Sfuncall);
   defsubr (&Sfunc_arity);


-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Sat, 25 Nov 2023 12:40:03 +0000
> Cc: monnier@iro.umontreal.ca, 67196@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> > What I had in mind was a function exposed to Lisp that would set an
> > internal variable not exposed to Lisp.
> 
> The would still require an unwind-protect somewhere.

We can unwind-protect in C as well.

> > > 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?
> 
> Yes, but that might be complicated, and won't help the user trying to
> debug something which depends on debug-on-error, who is using M-: to try
> to test it.

I don't see how that could happen.

> > 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?
> 
> I don't see that in my current version of the patch (below).  To test
> this, I used the following:
> 
> (defun foo ()
>   (interactive)
>   (message "debug-on-error is %s" debug-on-error)
>   (message "eval-expression-debug-on-error is %s" eval-expression-debug-on-error)
>   (car 'foo))
> 
> , and called it with various settings of debug-on-error and
> eval-expression-debug-on-error.  In particular, with
> 
>   (setq eval-expression-debug-on-error '(wrong-type-argument))
> 
> , I still see debug-on-error reported as nil.

No, I meant with the current code debug-on-error is set to t whenever
eval-expression-debug-on-error is non-nil, and your change sets it to
the same value as eval-expression-debug-on-error instead.

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

[Alan Mackenzie]

Hello, Eli.

On Sat, Nov 25, 2023 at 15:04:08 +0200, Eli Zaretskii wrote:
> > Date: Sat, 25 Nov 2023 12:40:03 +0000
> > Cc: monnier@iro.umontreal.ca, 67196@debbugs.gnu.org, acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

[ .... ]

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

> > I don't see that in my current version of the patch (below).  To test
> > this, I used the following:

> > (defun foo ()
> >   (interactive)
> >   (message "debug-on-error is %s" debug-on-error)
> >   (message "eval-expression-debug-on-error is %s" eval-expression-debug-on-error)
> >   (car 'foo))

> > , and called it with various settings of debug-on-error and
> > eval-expression-debug-on-error.  In particular, with

> >   (setq eval-expression-debug-on-error '(wrong-type-argument))

> > , I still see debug-on-error reported as nil.

> No, I meant with the current code debug-on-error is set to t whenever
> eval-expression-debug-on-error is non-nil, ....

Yes.

> .... and your change sets it to the same value as
> eval-expression-debug-on-error instead.

That is not what is meant to happen.  Instead, the new internal variable
debug-from--eval-expression gets set to e-e-debug-on-error.
debug-on-error should remain unchanged throughout a M-: call, leaving it
free for use by user code.  The subroutines of signal_or_quit test
debug-from--eval-expression in addition to testing debug-on-error.

Are you sure that isn't what you're seeing?

-- 
Alan Mackenzie (Nuremberg, Germany).

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]

> 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

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

[Eli Zaretskii]

> Date: Sat, 25 Nov 2023 14:14:59 +0000
> Cc: monnier@iro.umontreal.ca, 67196@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> > No, I meant with the current code debug-on-error is set to t whenever
> > eval-expression-debug-on-error is non-nil, ....
> 
> Yes.
> 
> > .... and your change sets it to the same value as
> > eval-expression-debug-on-error instead.
> 
> That is not what is meant to happen.

We are miscommunicating.

> Instead, the new internal variable
> debug-from--eval-expression gets set to e-e-debug-on-error.

Exactly.  And that value can be non-nil, but also not t.  That is the
change I see, and your doc string suggests that it is intentional.
Thus, we have a behavior change wrt to the value that the body of
eval-expression will see.  And non-nil, non-t values have special
meaning there.

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

[Alan Mackenzie]

Hello, Eli.

On Sat, Nov 25, 2023 at 17:50:09 +0200, Eli Zaretskii wrote:
> > Date: Sat, 25 Nov 2023 14:14:59 +0000
> > Cc: monnier@iro.umontreal.ca, 67196@debbugs.gnu.org, acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

> > > No, I meant with the current code debug-on-error is set to t whenever
> > > eval-expression-debug-on-error is non-nil, ....

> > Yes.

> > > .... and your change sets it to the same value as
> > > eval-expression-debug-on-error instead.

> > That is not what is meant to happen.

> We are miscommunicating.

> > Instead, the new internal variable
> > debug-from--eval-expression gets set to e-e-debug-on-error.

> Exactly.  And that value can be non-nil, but also not t.  That is the
> change I see, and your doc string suggests that it is intentional.
> Thus, we have a behavior change wrt to the value that the body of
> eval-expression will see.  And non-nil, non-t values have special
> meaning there.

OK, I'm with you, now.  The non-nil, non-t value in the internal variable
debug-from--e-e won't be seen by any Lisp code.  It can be seen by Lisp
code in eval-expression-debug-on-error.

This is an extension of e-e-debug-on-error to match what debug-on-error
does.  I wouldn't think that d-o-e gets set to a list of conditions very
often, but when it does, it's likely very useful.  It seemed logical to
extend the same facility to e-e-debug-on-error.  Do you think this is a
bad idea?  [Clearly, some entries in NEWS will be needed, as well as
amendments to the Elisp manual.]

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Sat, 25 Nov 2023 16:40:40 +0000
> Cc: monnier@iro.umontreal.ca, 67196@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> > > Instead, the new internal variable
> > > debug-from--eval-expression gets set to e-e-debug-on-error.
> 
> > Exactly.  And that value can be non-nil, but also not t.  That is the
> > change I see, and your doc string suggests that it is intentional.
> > Thus, we have a behavior change wrt to the value that the body of
> > eval-expression will see.  And non-nil, non-t values have special
> > meaning there.
> 
> OK, I'm with you, now.  The non-nil, non-t value in the internal variable
> debug-from--e-e won't be seen by any Lisp code.  It can be seen by Lisp
> code in eval-expression-debug-on-error.
> 
> This is an extension of e-e-debug-on-error to match what debug-on-error
> does.  I wouldn't think that d-o-e gets set to a list of conditions very
> often, but when it does, it's likely very useful.  It seemed logical to
> extend the same facility to e-e-debug-on-error.  Do you think this is a
> bad idea?  [Clearly, some entries in NEWS will be needed, as well as
> amendments to the Elisp manual.]

I don't know yet if it is a good idea, I just wanted to point out that
your change is not just a bugfix: it actually changes the behavior of
eval-expression.

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

[Alan Mackenzie]

Hello, Eli.

On Sat, Nov 25, 2023 at 18:46:05 +0200, Eli Zaretskii wrote:
> > Date: Sat, 25 Nov 2023 16:40:40 +0000
> > Cc: monnier@iro.umontreal.ca, 67196@debbugs.gnu.org, acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

> > > > Instead, the new internal variable
> > > > debug-from--eval-expression gets set to e-e-debug-on-error.

> > > Exactly.  And that value can be non-nil, but also not t.  That is the
> > > change I see, and your doc string suggests that it is intentional.
> > > Thus, we have a behavior change wrt to the value that the body of
> > > eval-expression will see.  And non-nil, non-t values have special
> > > meaning there.

> > OK, I'm with you, now.  The non-nil, non-t value in the internal variable
> > debug-from--e-e won't be seen by any Lisp code.  It can be seen by Lisp
> > code in eval-expression-debug-on-error.

> > This is an extension of e-e-debug-on-error to match what debug-on-error
> > does.  I wouldn't think that d-o-e gets set to a list of conditions very
> > often, but when it does, it's likely very useful.  It seemed logical to
> > extend the same facility to e-e-debug-on-error.  Do you think this is a
> > bad idea?  [Clearly, some entries in NEWS will be needed, as well as
> > amendments to the Elisp manual.]

> I don't know yet if it is a good idea, I just wanted to point out that
> your change is not just a bugfix: it actually changes the behavior of
> eval-expression.

OK.  It's a change that would be trivially easy to reverse.

My guess is that debug-on-error was originally a DEFVAR_BOOL, and at some
stage it was extended to handle a list of conditions.  But for some
reason eval-expression-debug-on-error was not extended in the same way.
Perhaps this was an oversight.  If so, now would be a good time to fix
this.

Maybe there is some evidence of what happened in the repository.  I'll
have a look.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Alan Mackenzie]

Hello again, Eli.

On Sat, Nov 25, 2023 at 16:57:21 +0000, Alan Mackenzie wrote:
> On Sat, Nov 25, 2023 at 18:46:05 +0200, Eli Zaretskii wrote:
> > > Date: Sat, 25 Nov 2023 16:40:40 +0000
> > > Cc: monnier@iro.umontreal.ca, 67196@debbugs.gnu.org, acm@muc.de
> > > From: Alan Mackenzie <acm@muc.de>

> > > > > Instead, the new internal variable
> > > > > debug-from--eval-expression gets set to e-e-debug-on-error.

> > > > Exactly.  And that value can be non-nil, but also not t.  That is the
> > > > change I see, and your doc string suggests that it is intentional.
> > > > Thus, we have a behavior change wrt to the value that the body of
> > > > eval-expression will see.  And non-nil, non-t values have special
> > > > meaning there.

> > > OK, I'm with you, now.  The non-nil, non-t value in the internal variable
> > > debug-from--e-e won't be seen by any Lisp code.  It can be seen by Lisp
> > > code in eval-expression-debug-on-error.

> > > This is an extension of e-e-debug-on-error to match what debug-on-error
> > > does.  I wouldn't think that d-o-e gets set to a list of conditions very
> > > often, but when it does, it's likely very useful.  It seemed logical to
> > > extend the same facility to e-e-debug-on-error.  Do you think this is a
> > > bad idea?  [Clearly, some entries in NEWS will be needed, as well as
> > > amendments to the Elisp manual.]

> > I don't know yet if it is a good idea, I just wanted to point out that
> > your change is not just a bugfix: it actually changes the behavior of
> > eval-expression.

> OK.  It's a change that would be trivially easy to reverse.

> My guess is that debug-on-error was originally a DEFVAR_BOOL, and at some
> stage it was extended to handle a list of conditions.  But for some
> reason eval-expression-debug-on-error was not extended in the same way.
> Perhaps this was an oversight.  If so, now would be a good time to fix
> this.

> Maybe there is some evidence of what happened in the repository.  I'll
> have a look.

eval-expression-debug-on-error came into existence with this commit:

commit b49df39ddcfc578234530208eba8e288f604db1b
Author: Richard M. Stallman <rms@gnu.org>
Date:   Tue Sep 14 07:00:04 1999 +0000

    (eval-expression-print-level): New variable.
    (eval-expression-print-length): New variable.
    (eval-expression-debug-on-error): New variable.
    (eval-expression): Bind print-level, print-length and
    debug-on-error from those vars.

..  debug-on-error got its list value with this commit:

commit 128c0f667926dd4296411b9189125ee8c5b78b79
Author: Roland McGrath <roland@gnu.org>
Date:   Thu Jun 4 04:33:43 1992 +0000

    *** empty log message ***

..  So debug-on-error had its list of conditions value 7 years before
eval-expression-debug-on-error existed.  It's not clear why this new
variable didn't take over the enhanced semantics from debug-on-error.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Andreas Schwab]

On Nov 25 2023, Alan Mackenzie wrote:

> My guess is that debug-on-error was originally a DEFVAR_BOOL, and at some
> stage it was extended to handle a list of conditions.  But for some
> reason eval-expression-debug-on-error was not extended in the same way.

There is no need to extend eval-expression-debug-on-error.  Just set it
to nil to let eval-expression use the value of debug-on-error as usual.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."