bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alan Mackenzie
Subject: bug#67196: M-: uses a wrong value of debug-on-error when it is nil.
Date: Sat, 25 Nov 2023 16:57:21 +0000

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]