bug#3466: 23.0.94; have `d' in debugger treat macro expansion like `c' does

bug#3466: 23.0.94; have `d' in debugger treat macro expansion like `c' does

[Drew Adams]

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

bug#3466: 23.0.94; have `d' in debugger treat macro expansion like `c' does

[Lars Ingebrigtsen]

"Drew Adams" <drew.adams@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

bug#3466: [External] : Re: bug#3466: 23.0.94; have `d' in debugger treat macro expansion like `c' does

[Drew Adams]

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

bug#3466: [External] : Re: bug#3466: 23.0.94; have `d' in debugger treat macro expansion like `c' does

[Lars Ingebrigtsen]

Drew Adams <drew.adams@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

bug#3466: 23.0.94; have `d' in debugger treat macro expansion like `c' does

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@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.

bug#3466: 23.0.94; have `d' in debugger treat macro expansion like `c' does

[Drew Adams]

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

bug#3466: 23.0.94; have `d' in debugger treat macro expansion like `c' does

[Michael Heerdegen]

Drew Adams <drew.adams@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.