bug#47516: 28.0.50; void-variable edebug-all-defs

[martin rudalics]

For decades I'm used to debug Lisp functions by calling `edebug-defun'.
To get rid of the debugging instrumentation I'm using `eval-buffer'.  In
the not so distant past Emacs started to complain about this habit as
follows:


Debugger entered--Lisp error: (void-variable edebug-all-defs)
   edebug-read-and-maybe-wrap-form1()
   edebug-read-and-maybe-wrap-form()
   edebug--read(read #<buffer window.el>)
   apply(edebug--read read #<buffer window.el>)
   #f(advice-wrapper :around read edebug--read)(#<buffer window.el>)
   eval-buffer()  ; Reading at buffer position 990
   funcall-interactively(eval-buffer)
   call-interactively(eval-buffer nil nil)
   command-execute(eval-buffer)


I neither understand the error message nor why I should not be allowed
to evaluate the buffer in this situation.

martin

[Philipp Stephani]

Am Mi., 31. März 2021 um 10:11 Uhr schrieb martin rudalics <[hidden email]>:

>
> For decades I'm used to debug Lisp functions by calling `edebug-defun'.
> To get rid of the debugging instrumentation I'm using `eval-buffer'.  In
> the not so distant past Emacs started to complain about this habit as
> follows:
>
>
> Debugger entered--Lisp error: (void-variable edebug-all-defs)
>    edebug-read-and-maybe-wrap-form1()
>    edebug-read-and-maybe-wrap-form()
>    edebug--read(read #<buffer window.el>)
>    apply(edebug--read read #<buffer window.el>)
>    #f(advice-wrapper :around read edebug--read)(#<buffer window.el>)
>    eval-buffer()  ; Reading at buffer position 990
>    funcall-interactively(eval-buffer)
>    call-interactively(eval-buffer nil nil)
>    command-execute(eval-buffer)
>
>
> I neither understand the error message nor why I should not be allowed
> to evaluate the buffer in this situation.
>

 Not sure whether it's related, but there's a comment in edebug.el:

;; edebug-all-defs and edebug-all-forms need to be autoloaded
;; because the byte compiler binds them; as a result, if edebug
;; is first loaded for a require in a compilation, they will be left unbound.

But despite this explanation these two variables aren't autoloaded.

[Michael Heerdegen]

Stefan,

You removed that autoload cookie in bae2cfe63c:

| * lisp/emacs-lisp/edebug.el (eval-defun): Simplify
|
| (edebug-all-defs, edebug-all-forms): Don't autoload since the problem
| it was working around has been fixed a while back.

Seems that was hasty - or not the only problem these autoload cured?

Philipp Stephani <[hidden email]> writes:

> > For decades I'm used to debug Lisp functions by calling `edebug-defun'.
> > To get rid of the debugging instrumentation I'm using `eval-buffer'.  In
> > the not so distant past Emacs started to complain about this habit as
> > follows:
> >
> > Debugger entered--Lisp error: (void-variable edebug-all-defs)
> >    edebug-read-and-maybe-wrap-form1()
> >    edebug-read-and-maybe-wrap-form()
> >    edebug--read(read #<buffer window.el>)
> >    apply(edebug--read read #<buffer window.el>)
> >    #f(advice-wrapper :around read edebug--read)(#<buffer window.el>)
> >    eval-buffer()  ; Reading at buffer position 990
> >    funcall-interactively(eval-buffer)
> >    call-interactively(eval-buffer nil nil)
> >    command-execute(eval-buffer)
> >
> > I neither understand the error message nor why I should not be allowed
> > to evaluate the buffer in this situation.
> >
>
>  Not sure whether it's related, but there's a comment in edebug.el:
>
> ;; edebug-all-defs and edebug-all-forms need to be autoloaded
> ;; because the byte compiler binds them; as a result, if edebug
> ;; is first loaded for a require in a compilation, they will be left
> unbound.
>
> But despite this explanation these two variables aren't autoloaded.

TIA,

Michael.

[martin rudalics]

 > Do you have some extra info about how to reproduce this?
 > I tried `M-x eval-buffer` inside `lisp/window.el` but that didn't signal
 > any problem, neither before nor after loading `edebug.el`.

Suppose I put point within a function like `window-min-pixel-height' and
then type C-M-# which here

   runs the command edebug-defun (found in edebug-mode-map), which is
   an alias for ‘edebug-eval-top-level-form’ in ‘edebug.el’.

insert (window-min-pixel-height) into *scratch* and do C-x e and debug
that call.  When I now type M-# in window.el which here

   runs the command eval-buffer (found in edebug-mode-map), which is an
   interactive built-in function in ‘C source code’.

I get

Debugger entered--Lisp error: (void-variable edebug-all-defs)
   edebug-read-and-maybe-wrap-form1()
   edebug-read-and-maybe-wrap-form()
   edebug--read(read #<buffer window.el>)
   apply(edebug--read read #<buffer window.el>)
   #f(advice-wrapper :around read edebug--read)(#<buffer window.el>)
   eval-buffer()  ; Reading at buffer position 990
   funcall-interactively(eval-buffer)
   call-interactively(eval-buffer nil nil)
   command-execute(eval-buffer)

Quitting *Backtrace* - I have (debug-on-error t) - and typing M-# again
gets me that "error" again and again.

Three settings in my custom-set-variables section which might be related
are

  '(edebug-on-error nil)
  '(edebug-on-quit nil)
  '(edebug-print-level 50)

martin

[Stefan Monnier]

> Suppose I put point within a function like `window-min-pixel-height' and
> then type C-M-# which here
>
>   runs the command edebug-defun (found in edebug-mode-map), which is
>   an alias for ‘edebug-eval-top-level-form’ in ‘edebug.el’.

Hmm... this is a bit odd: `edebug-mode-map` is the map used when we're
stepping through execution with Edebug, so are you saying that Edebug
was already in use before this `edebug-defun`?

> insert (window-min-pixel-height) into *scratch* and do C-x e and debug
> that call.  When I now type M-# in window.el which here
>
>   runs the command eval-buffer (found in edebug-mode-map), which is an
>   interactive built-in function in ‘C source code’.
>
> I get
>
> Debugger entered--Lisp error: (void-variable edebug-all-defs)

Hmm... still can't reproduce it here.  Can you reproduce it with `emacs -Q`?

Also (stab in the dark), could you check (boundp 'edebug-all-defs) in
a few different buffers?


        Stefan

[Stefan Monnier]

>> Hmm... still can't reproduce it here.  Can you reproduce it with `emacs -Q`?
>>
>> Also (stab in the dark), could you check (boundp 'edebug-all-defs) in
>> a few different buffers?
>
> Maybe I found it.  For whatever reson I have
>
>     (make-local-variable 'edebug-all-defs)
>
> in my emacs-lisp-mode-hook.  Apparently, I needed it many years ago and
> it wasn't in the way till a couple of weeks or months ago.

Oh, so it ends up making the variable buffer-local before it gets
initialized, so it's both globally unbound and buffer-locally unbound.
Hence when the `defvar` is processed the global value gets initialized
but the buffer-local value stays unbound.

Do you happen to remember why you "needed it many years ago"?

I'm leaning towards considering this a "pilot error".


        Stefan