bug#26847: 26.0.50; Using edebug-step-in on a macro switches to go-mode

bug#26847: 26.0.50; Using edebug-step-in on a macro switches to go-mode

[Gemini Lasswell]

edebug-step-in doesn't behave well when you try to use it on a
macro. For an example, enter the following code in *scratch*:
  
(setq my-things nil)
(defun my-try-thing (thing)
  (push thing my-things))

Then:

M-x eval-buffer RET
navigate to my-try-thing and C-u C-M-x
M-: (my-try-thing 'a) RET
i

Result: Edebug exits and code runs to completion, result printed in
minibuffer.

Then navigate to my-try-thing again and C-M-x

Result: Edebug activates with the debugger prompt in `push'.

Stepping into macros would have made sense before eager
macro-expansion, but now by the time Edebug instruments the code the
macro has already run. Probably the simplest thing to do here is to
have edebug-step-in signal an error if asked to step into a macro. The
documentation for edebug-step-in also should be updated to remove
mention of stepping into macros.

bug#26847: 26.0.50; Using edebug-step-in on a macro switches to go-mode

[Dmitry Gutov]

On 09.05.2017 0:06, Gemini Lasswell wrote:

> Stepping into macros would have made sense before eager
> macro-expansion, but now by the time Edebug instruments the code the
> macro has already run. Probably the simplest thing to do here is to
> have edebug-step-in signal an error if asked to step into a macro. The
> documentation for edebug-step-in also should be updated to remove
> mention of stepping into macros.

Since nobody has complained about this problem by now, it's probably the 
easiest solution indeed.

However, I wonder if we could inhibit eager macro-expansion when a 
function is being instrumented by edebug. Its definition is being 
re-evaluated at that time, right?

I don't know if we have a good way to do that, though. Or if adding one 
ends up being easy to maintain.

bug#26847: 26.0.50; Using edebug-step-in on a macro switches to go-mode

[Lars Ingebrigtsen]

Gemini Lasswell <gazally@runbox.com> writes:

> edebug-step-in doesn't behave well when you try to use it on a
> macro. For an example, enter the following code in *scratch*:
>
> (setq my-things nil)
> (defun my-try-thing (thing)
>   (push thing my-things))
>
> Then:
>
> M-x eval-buffer RET
> navigate to my-try-thing and C-u C-M-x
> M-: (my-try-thing 'a) RET
> i
>
> Result: Edebug exits and code runs to completion, result printed in
> minibuffer.

I'm unable to reproduce this in Emacs 27.  When I hit `i', I'm then
edebugging the `push' macro, and then I can step through it, and then
I'm back to stepping through my-try-thing.

Are you still seeing this bug in Emacs 27?

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

bug#26847: 26.0.50; Using edebug-step-in on a macro switches to go-mode

[Gemini Lasswell]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I'm unable to reproduce this in Emacs 27.  When I hit `i', I'm then
> edebugging the `push' macro, and then I can step through it, and then
> I'm back to stepping through my-try-thing.
>
> Are you still seeing this bug in Emacs 27?

In Emacs 26, eager macro expansion happened when instrumenting code for
Edebug using eval-defun.  In current master, it's not getting done.
Looking at (symbol-function 'my-try-thing) in both versions will show
you the difference.

The lack of macroexpansion doesn't only happen when instrumenting for
Edebug.  If you evaluate a function definition with eval-buffer or
eval-last-sexp then macroexpansion is done, but if you evaluate it with
eval-defun with or without the universal argument, then no
macroexpansion happens. This is a change from Emacs 26, and is masking
the original bug.

If you use these steps to reproduce, with the same sample code:

M-x edebug-all-defs RET
M-x eval-buffer RET
M-: (my-try-thing 'a) RET
i

then the original bug still occurs.

bug#26847: 26.0.50; Using edebug-step-in on a macro switches to go-mode

[Lars Ingebrigtsen]

Gemini Lasswell <gazally@runbox.com> writes:

> If you use these steps to reproduce, with the same sample code:
>
> M-x edebug-all-defs RET
> M-x eval-buffer RET
> M-: (my-try-thing 'a) RET
> i
>
> then the original bug still occurs.

Yup.

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