GNU bug report logs - #3466
23.0.94; have `d' in debugger treat macro expansion like `c' does

Previous Next

Package: emacs;

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

Date: Wed, 3 Jun 2009 21:50:03 UTC

Severity: wishlist

Done: Michael Heerdegen <michael_heerdegen <at> web.de>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#3466; Package emacs. (Wed, 03 Jun 2009 21:50:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Drew Adams" <drew.adams <at> oracle.com>:
New bug report received and forwarded. Copy sent to Emacs Bugs <bug-gnu-emacs <at> gnu.org>. (Wed, 03 Jun 2009 21:50:04 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <emacs-pretest-bug <at> gnu.org>
Subject: 23.0.94; have `d' in debugger treat macro expansion like `c' does
Date: Wed, 3 Jun 2009 14:44:00 -0700
Feature request -
 
In the Lisp debugger (the one for `debug-on-entry' etc.), if you're
going along doing `d, d, d...', and you get to a Lisp macro, such as
`dolist', you must switch to `c' instead of `d', if you don't want to
drill down into the steps of the macro expansion itself.
 
It would be good to be able to optionally have `d' skip over macro
expansions (that is, expand all at once, like `c' does). A new user
option could control this.
 
[Alternatively, we could have a different key from `d', say `s' (for
"step"), that does this always - does what `d' does except for macros,
where it does what `c' does. But I suspect a user option would be
sufficient - you probably either want to do this all the time or you
don't (no need for two different stepping keys).]
 
With the alternative behavior, in `dolist', for example, you would
step through the function calls, using `d', and automatically skip
over the macro expansions, also using `d'. There are two macro
expansions for `dolist': #[(spec &rest body) "...] for `dolist' itself
and #[(name &rest body) "...] for `block'. No need to switch from `d'
to `c' for those expansions. In something like `dolist', you typically
just want to get quickly to the loop iterations.
 
Using the debugger with things like `dolist' (which I've been doing
for years) is a pain, compared to using the debugger with, say,
`while'. It's almost enough of a pain to make one avoid using `dolist'
and such.
 
In GNU Emacs 23.0.94.1 (i386-mingw-nt5.1.2600)
 of 2009-05-24 on SOFT-MJASON
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'
 




Severity set to `wishlist' from `normal' Request was from Chong Yidong <cyd <at> stupidchicken.com> to control <at> emacsbugs.donarmstrong.com. (Thu, 04 Jun 2009 01:45:05 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#3466; Package emacs. (Thu, 03 Jun 2021 10:05:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 3466 <at> debbugs.gnu.org
Subject: Re: bug#3466: 23.0.94; have `d' in debugger treat macro expansion
 like `c' does
Date: Thu, 03 Jun 2021 12:04:12 +0200
"Drew Adams" <drew.adams <at> oracle.com> writes:

> In the Lisp debugger (the one for `debug-on-entry' etc.), if you're
> going along doing `d, d, d...', and you get to a Lisp macro, such as
> `dolist', you must switch to `c' instead of `d', if you don't want to
> drill down into the steps of the macro expansion itself.
>
> It would be good to be able to optionally have `d' skip over macro
> expansions (that is, expand all at once, like `c' does). A new user
> option could control this.

I'm not quite sure I understand you here -- `c' evaluates (and skips)
the entire expression, so you don't get to see what it's doing "inside"
the macro.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Added tag(s) moreinfo. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Thu, 03 Jun 2021 10:05:01 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#3466; Package emacs. (Thu, 03 Jun 2021 15:02:02 GMT) Full text and rfc822 format available.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "3466 <at> debbugs.gnu.org" <3466 <at> debbugs.gnu.org>
Subject: RE: [External] : Re: bug#3466: 23.0.94; have `d' in debugger treat
 macro expansion like `c' does
Date: Thu, 3 Jun 2021 15:01:04 +0000
> > In the Lisp debugger (the one for `debug-on-entry' etc.), if you're
> > going along doing `d, d, d...', and you get to a Lisp macro, such as
> > `dolist', you must switch to `c' instead of `d', if you don't want to
> > drill down into the steps of the macro expansion itself.
> >
> > It would be good to be able to optionally have `d' skip over macro
> > expansions (that is, expand all at once, like `c' does). A new user
> > option could control this.
> 
> I'm not quite sure I understand you here -- `c' evaluates (and skips)
> the entire expression, so you don't get to see what it's doing "inside"
> the macro.

You hit `d' once, to get into the macro, then `c' to get
the macro expansion (then d d d... to go on after the
expansion).

The point was only that at some point you need to hit `c'
if you don't want to do the macro expansion itself step
by step.

Here's an excerpt from a *Backtrace* that shows the macro
expansion: (let ((...))...).

Debugger entered--returning value: (let ((--dolist-tail-- (buffer-list)) b) ...
  #f(compiled-function (arg1 &rest rest) "Loop over a list.\nEvaluate BODY with ...
* apply(#f(compiled-function (arg1 &rest rest) "Loop over a list.\nEvaluate BODY ...
* cl--wrap-in-nil-block(#f(compiled-function (arg1 &rest rest) "Loop over a list ...
* apply(cl--wrap-in-nil-block #f(compiled-function (arg1 &rest rest) "Loop over a ...
* #f(advice-wrapper :around #f(compiled-function (arg1 &rest rest) "Loop over a list...
* (dolist (b (buffer-list)) (message "Buf: %s" (buffer-name b)))
* (lambda nil (dolist (b (buffer-list)) (message "Buf: %s" (buffer-name b))))()
* apply((lambda nil (dolist (b (buffer-list)) (message "Buf: %s" (buffer-name b)))) nil)
* foo()

At least that's what I think this was about (the bug was
reported 12 years ago).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#3466; Package emacs. (Fri, 04 Jun 2021 09:24:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: "3466 <at> debbugs.gnu.org" <3466 <at> debbugs.gnu.org>
Subject: Re: [External] : Re: bug#3466: 23.0.94; have `d' in debugger treat
 macro expansion like `c' does
Date: Fri, 04 Jun 2021 11:22:51 +0200
Drew Adams <drew.adams <at> oracle.com> writes:

> You hit `d' once, to get into the macro, then `c' to get
> the macro expansion (then d d d... to go on after the
> expansion).
>
> The point was only that at some point you need to hit `c'
> if you don't want to do the macro expansion itself step
> by step.

Hm.  I'm not all that familiar with this debugging interface -- I
usually use edebug, so I'm not quite sure what people expect from this
thing.

So here's my test case:

(defun foo ()
  (dotimes (i 2)
    (message "foo")))

and `M-x debug-on-entry' on foo, `M-: (foo)', just hitting `d' a lot
does what I'd expect -- stepping through all the code.  It does not seem
to step the through the macro expansion itself.  (At least not in Emacs
27.1 or 28.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Removed tag(s) moreinfo. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Fri, 02 Jul 2021 11:20:03 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#3466; Package emacs. (Thu, 20 Oct 2022 02:05:02 GMT) Full text and rfc822 format available.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "3466 <at> debbugs.gnu.org" <3466 <at> debbugs.gnu.org>,
 Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#3466: 23.0.94; have `d' in debugger treat macro expansion
 like `c' does
Date: Thu, 20 Oct 2022 04:04:44 +0200
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> So here's my test case:
>
> (defun foo ()
>   (dotimes (i 2)
>     (message "foo")))
>
> and `M-x debug-on-entry' on foo, `M-: (foo)', just hitting `d' a lot
> does what I'd expect -- stepping through all the code.  It does not seem
> to step the through the macro expansion itself.  (At least not in Emacs
> 27.1 or 28.)

I also don't understand what Drew writes.  Especially why c would do
something that a repeated d would not get you to, sooner or later.

Drew, did you bind c to something else?  Or had your code been loaded
under some special conditions?  Normally what the debugger steps through
doesn't contain macro calls - even for uncompiled code and even for the
dynamically binding dialect.  So unless you were debugging quoted
lambdas, I'm ... confused.

Michael.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#3466; Package emacs. (Thu, 20 Oct 2022 16:05:02 GMT) Full text and rfc822 format available.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>, Lars Ingebrigtsen
 <larsi <at> gnus.org>
Cc: "3466 <at> debbugs.gnu.org" <3466 <at> debbugs.gnu.org>
Subject: RE: [External] : Re: bug#3466: 23.0.94; have `d' in debugger treat
 macro expansion like `c' does
Date: Thu, 20 Oct 2022 16:04:04 +0000
> > (defun foo () (dotimes (i 2) (message "foo")))
> >
> > and `M-x debug-on-entry' on foo, `M-: (foo)', just hitting `d' a lot
> > does what I'd expect -- stepping through all the code.  It does not seem
> > to step the through the macro expansion itself.  (At least not in Emacs
> > 27.1 or 28.)
> 
> I also don't understand what Drew writes.  Especially why c would do
> something that a repeated d would not get you to, sooner or later.

Nothing in the enhancement request suggested that `c'
does anything that repeated `d' won't do.  The point
was to (optionally) have some particular repetitions
of `d' be handled like `c': skip over the need to
repeat `d' for those cases.  Which cases: macro
expansions.

> Drew, did you bind c to something else?  Or had your code been loaded
> under some special conditions?  Normally what the debugger steps through
> doesn't contain macro calls - even for uncompiled code and even for the
> dynamically binding dialect.  So unless you were debugging quoted
> lambdas, I'm ... confused.

I appreciate the attention to the bug report, but it
was reported 14 years ago.  Well, let's see.

I think the point of the enhancement request was to
optionally be able to have `d' in the debugger act
like `c' when a macro is encountered - only to expand
the macro, not to evaluate the result of expansion.
More precisely, act like `c' when the macro expression
to be expanded would be shown.

`dolist' is a macro.  In Emacs 23 (which is when the
request was filed), you see this, if you use
(debug-on-entry 'foo), for this code:

(setq xs '((1 2) 42 (a b c)))
(defun foo ()
  (dolist (x xs)
    (message "%S" x)))

Debugger entered--entering a function:
* append(((message "%S" x)) ((setq --dolist-tail-- (cdr --dolist-tail--))))
* #[(spec &rest body) ...
* (dolist (x xs) (message "%S" x))
* foo()
  eval((foo))
  eval-expression((foo) nil)
  call-interactively(eval-expression)

The point was to (be able to, optionally) have `d' on
the #[(spec &rest body) ... line (not the `dolist'
line) act like `c' there - immediately giving the
result of its expansion.

Now, in more recent versions of Emacs you don't see
the (dolist...) line at all; you directly see `while'
instead:

Debugger entered--beginning evaluation of function call form:
* (while --dolist-tail-- ...
* (let ((--dolist-tail-- xs) x) (while --dolist-tail...
* (lambda nil (let ((--dolist-tail-- xs) x) (while --dolist-tail...
* apply((lambda nil (let ((--dolist-tail-- xs) x) (while --dolist-tail--...
* foo()
  eval((foo) t)
  eval-expression((foo) nil nil 127)
  funcall-interactively(eval-expression (foo) nil nil 127)
  call-interactively(eval-expression nil nil)
  command-execute(eval-expression)

That's fine.  Emacs was enhanced as requested.




Reply sent to Michael Heerdegen <michael_heerdegen <at> web.de>:
You have taken responsibility. (Thu, 20 Oct 2022 20:39:02 GMT) Full text and rfc822 format available.

Notification sent to "Drew Adams" <drew.adams <at> oracle.com>:
bug acknowledged by developer. (Thu, 20 Oct 2022 20:39:02 GMT) Full text and rfc822 format available.

Message #31 received at 3466-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 3466-done <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: [External] : Re: bug#3466: 23.0.94; have `d' in debugger treat
 macro expansion like `c' does
Date: Thu, 20 Oct 2022 22:38:07 +0200
Drew Adams <drew.adams <at> oracle.com> writes:

> That's fine.  Emacs was enhanced as requested.

Very good.  Ok, thanks for testing and rethinking.  So were are done,
and I am closing this report.

Michael.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Fri, 18 Nov 2022 12:24:07 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 131 days ago.

Previous Next


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