unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#3466: 23.0.94; have `d' in debugger treat macro expansion like `c' does
@ 2009-06-03 21:44 Drew Adams
  2021-06-03 10:04 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 7+ messages in thread
From: Drew Adams @ 2009-06-03 21:44 UTC (permalink / raw)
  To: emacs-pretest-bug

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






^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#3466: 23.0.94; have `d' in debugger treat macro expansion like `c' does
  2009-06-03 21:44 bug#3466: 23.0.94; have `d' in debugger treat macro expansion like `c' does Drew Adams
@ 2021-06-03 10:04 ` Lars Ingebrigtsen
  2021-06-03 15:01   ` bug#3466: [External] : " Drew Adams
  0 siblings, 1 reply; 7+ messages in thread
From: Lars Ingebrigtsen @ 2021-06-03 10:04 UTC (permalink / raw)
  To: Drew Adams; +Cc: 3466

"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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#3466: [External] : Re: bug#3466: 23.0.94; have `d' in debugger treat macro expansion like `c' does
  2021-06-03 10:04 ` Lars Ingebrigtsen
@ 2021-06-03 15:01   ` Drew Adams
  2021-06-04  9:22     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 7+ messages in thread
From: Drew Adams @ 2021-06-03 15:01 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 3466@debbugs.gnu.org

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#3466: [External] : Re: bug#3466: 23.0.94; have `d' in debugger treat macro expansion like `c' does
  2021-06-03 15:01   ` bug#3466: [External] : " Drew Adams
@ 2021-06-04  9:22     ` Lars Ingebrigtsen
  2022-10-20  2:04       ` Michael Heerdegen
  0 siblings, 1 reply; 7+ messages in thread
From: Lars Ingebrigtsen @ 2021-06-04  9:22 UTC (permalink / raw)
  To: Drew Adams; +Cc: 3466@debbugs.gnu.org

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#3466: 23.0.94; have `d' in debugger treat macro expansion like `c' does
  2021-06-04  9:22     ` Lars Ingebrigtsen
@ 2022-10-20  2:04       ` Michael Heerdegen
  2022-10-20 16:04         ` Drew Adams
  0 siblings, 1 reply; 7+ messages in thread
From: Michael Heerdegen @ 2022-10-20  2:04 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 3466@debbugs.gnu.org, Drew Adams

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.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#3466: 23.0.94; have `d' in debugger treat macro expansion like `c' does
  2022-10-20  2:04       ` Michael Heerdegen
@ 2022-10-20 16:04         ` Drew Adams
  2022-10-20 20:38           ` Michael Heerdegen
  0 siblings, 1 reply; 7+ messages in thread
From: Drew Adams @ 2022-10-20 16:04 UTC (permalink / raw)
  To: Michael Heerdegen, Lars Ingebrigtsen; +Cc: 3466@debbugs.gnu.org

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#3466: 23.0.94; have `d' in debugger treat macro expansion like `c' does
  2022-10-20 16:04         ` Drew Adams
@ 2022-10-20 20:38           ` Michael Heerdegen
  0 siblings, 0 replies; 7+ messages in thread
From: Michael Heerdegen @ 2022-10-20 20:38 UTC (permalink / raw)
  To: Drew Adams; +Cc: 3466-done, Lars Ingebrigtsen

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.





^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2022-10-20 20:38 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-06-03 21:44 bug#3466: 23.0.94; have `d' in debugger treat macro expansion like `c' does Drew Adams
2021-06-03 10:04 ` Lars Ingebrigtsen
2021-06-03 15:01   ` bug#3466: [External] : " Drew Adams
2021-06-04  9:22     ` Lars Ingebrigtsen
2022-10-20  2:04       ` Michael Heerdegen
2022-10-20 16:04         ` Drew Adams
2022-10-20 20:38           ` Michael Heerdegen

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).