GNU bug report logs - #13061
24.3.50; regressions: 1) Redefining a function should cancel `debug-on-entry', 2) doc

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13061 in the body.
You can then email your comments to 13061 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.3.50;
	regressions: 1) Redefining a function should cancel `debug-on-entry',
	2) doc
Date: Sun, 2 Dec 2012 11:47:06 -0800

1.
 
emacs -Q

(defun foo (&optional n)
  (interactive "p")
  (forward-char n))
 
M-x debug-on-entry RET foo RET
 
M-x foo ; enters the debugger
 
Then C-M-x on the defun above, to redefine foo.
 
M-x foo ; STILL enters the debugger

You can even add a doc string or make another change, then C-M-x, and you will
STILL enter the debugger when `foo' is invoked.
 
Redefining foo should cancel the `debug-on-entry'.  See (elisp)
`Function Debugging':
 
  *Warning:* if you redefine a function after using `debug-on-entry'
  on it, the code to enter the debugger is discarded by the
  redefinition.  In effect, redefining the function cancels the
  break-on-entry feature for that function.
 
This feature has now been broken.  Please restore it.
 
It is a hell of a lot easier to hit C-M-x on foo's definition than it is
to do `M-x cancel-debug-on-entry RET foo RET'.
 

2. In the Elisp manual, this should NOT be a *Warning*.  This is an
intentional, longstanding FEATURE, not something bad to be warned about.
 
And this WAS NOT a *Warning* but a simple *Note*, prior to Emacs 22.  This
mania of introducing "*WARNING*" everywhere really should stop.
 
This occurrence is a second regression.  "*Note*", and its attendant
sanity, should be restored here.
 
It would not be surprising if some misguided soul removed this feature
of debug cancellation by function redefinition precisely because of a
misunderstanding introduced by this *Warning*, thinking that this is not
a feature but something bad - a bug to be "fixed".
 
Far from being warned, as if this were about some bug workaround, users
should be positively informed about this feature.  That's what the
original *Note* was for: to draw their attention to this positively, not
to warn them about it as if it were something to avoid.
 
 
 
In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
 of 2012-11-19 on MS-W7-DANI
Bzr revision: 110950 monnier <at> iro.umontreal.ca-20121119182725-5p6w4wjimm7epggr
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -Ic:/emacs/libs/libXpm-3.5.10/include -Ic:/emacs/libs/libXpm-3.5.10/src
 -Ic:/emacs/libs/libpng-1.2.37-lib/include -Ic:/emacs/libs/zlib-1.2.5
 -Ic:/emacs/libs/giflib-4.1.4-1-lib/include
 -Ic:/emacs/libs/jpeg-6b-4-lib/include
 -Ic:/emacs/libs/tiff-3.8.2-1-lib/include
 -Ic:/emacs/libs/libxml2-2.7.8-w32-bin/include/libxml2
 -Ic:/emacs/libs/gnutls-3.0.9-w32-bin/include
 -Ic:/emacs/libs/libiconv-1.9.2-1-lib/include'
 

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <13061 <at> debbugs.gnu.org>
Subject: RE: bug#13061: 24.3.50;
	regressions: 1) Redefining a function should cancel
	`debug-on-entry',2) doc
Date: Sat, 8 Dec 2012 20:31:14 -0800

1. I really hope this regression gets fixed soon.  It's quite annoying that
redefining a function does not cancel `debug-on-entry' for it.


2. Wrt the recent abuse by Emacs Dev of the term "Warning": Think about the
terms they use for hurricanes and such, situations which are FAR more serious
than what Emacs has to deal with:

a. The first level of making people aware is called an "Advisory".

b. "Warning" is used only for a much higher level involving imminent danger.

The equivalent of "advisory" wrt documentation is generally "Note", "Notice", or
"Attention".  You are just drawing attention to a statement, without a
connotation of danger.

Emacs doc should stop being so alarmist, generally.  And in the case of this
bug, it is downright perverted to "warn" about a positive feature.

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <13061 <at> debbugs.gnu.org>
Subject: RE: bug#13061: 24.3.50; regressions: 1) Redefining a function should
	cancel`debug-on-entry',2) doc
Date: Fri, 14 Dec 2012 15:49:55 -0800

Could someone please take a look at this bug?

It is so simple to hit C-M-x when debugging and modifiying a function that has
`debug-on-entry'.  Doing that should (obviously) cancel opening the debugger on
entry.  This has always been the behavior in Emacs, and it should be a
no-brainer.

(I'm not saying that how to fix it is a no-brainer - just the fact that the sane
behavior should be restored.)

Thx.

> I really hope this regression gets fixed soon.  It's quite 
> annoying that redefining a function does not cancel
> `debug-on-entry' for it.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 13061 <at> debbugs.gnu.org
Subject: Re: bug#13061: 24.3.50; regressions: 1) Redefining a function should
	cancel`debug-on-entry',2) doc
Date: Sat, 15 Dec 2012 14:46:49 +0100

"Drew Adams" <drew.adams <at> oracle.com> writes:

> It is so simple to hit C-M-x when debugging and modifiying a function
> that has `debug-on-entry'.  Doing that should (obviously) cancel
> opening the debugger on entry.  This has always been the behavior in
> Emacs, and it should be a no-brainer.

Just one comment from another user: I like the opposite (that is, the
new) behavior.  It always annoyed me that e.g. loading file sources
canceled any according `debug-on-entry' in effect.  I prefer to use
`cancel-debug-on-entry' explicitly.

Maybe the behavior could be made configurable?


Regards,

Michael.

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Michael Heerdegen'" <michael_heerdegen <at> web.de>
Cc: 13061 <at> debbugs.gnu.org
Subject: RE: bug#13061: 24.3.50; regressions: 1) Redefining a function should
	cancel`debug-on-entry',2) doc
Date: Sat, 15 Dec 2012 08:05:22 -0800

> > It is so simple to hit C-M-x when debugging and modifiying 
> > a function that has `debug-on-entry'.  Doing that should
> > (obviously) cancel opening the debugger on entry.  This has
> > always been the behavior in Emacs, and it should be a no-brainer.
> 
> Just one comment from another user: I like the opposite (that is, the
> new) behavior.  It always annoyed me that e.g. loading file sources
> canceled any according `debug-on-entry' in effect.  I prefer to use
> `cancel-debug-on-entry' explicitly.
> 
> Maybe the behavior could be made configurable?

+1 - users use Emacs differently.

But the default behavior should be the longstanding behavior.
There is no reason to change that.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 13061 <at> debbugs.gnu.org
Subject: RE: bug#13061: 24.3.50; regressions: 1) Redefining a function
 shouldcancel`debug-on-entry',2) doc
Date: Wed, 2 Jul 2014 10:57:39 -0700 (PDT)

> > > It is so simple to hit C-M-x when debugging and modifiying
> > > a function that has `debug-on-entry'.  Doing that should
> > > (obviously) cancel opening the debugger on entry.  This has
> > > always been the behavior in Emacs, and it should be a no-brainer.
> >
> > Just one comment from another user: I like the opposite (that is, the
> > new) behavior.  It always annoyed me that e.g. loading file sources
> > canceled any according `debug-on-entry' in effect.  I prefer to use
> > `cancel-debug-on-entry' explicitly.
> >
> > Maybe the behavior could be made configurable?
> 
> +1 - users use Emacs differently.
> 
> But the default behavior should be the longstanding behavior.
> There is no reason to change that.

FWIW, I'm OK with the new behavior, even as the default behavior.

(I do think the behavior should be user configurable, however.  And
I think it is best not to change the default behavior, especially
without polling users.)

[And this bug should NOT have been merged with bug #17902, which
simply points out that the new behavior is not reflected in the doc.]

Previous Next

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