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

Previous Next

Package: emacs;

Reported by: Alan Mackenzie <acm <at> muc.de>

Date: Wed, 15 Nov 2023 17:03:02 UTC

Severity: normal

Done: Alan Mackenzie <acm <at> muc.de>

Bug is archived. No further changes may be made.

Full log


Message #77 received at 67196 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 67196 <at> debbugs.gnu.org, acm <at> muc.de, monnier <at> iro.umontreal.ca
Subject: Re: bug#67196: M-: uses a wrong value of debug-on-error when it is
 nil.
Date: Sat, 25 Nov 2023 17:36:37 +0000
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 <at> iro.umontreal.ca, 67196 <at> debbugs.gnu.org, acm <at> muc.de
> > > From: Alan Mackenzie <acm <at> 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 <at> 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 <at> 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).




This bug report was last modified 211 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.