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

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

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

[Philipp Stephani]

Am Mi., 31. März 2021 um 10:11 Uhr schrieb martin rudalics <rudalics@gmx.at>:
>
> 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.

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

[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 <p.stephani2@gmail.com> 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.

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

[Stefan Monnier]

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

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


        Stefan

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

[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

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

[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

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

[martin rudalics]

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

martin

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

[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

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

[martin rudalics]

 > 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"?

No.  But I just read the doc-string of `edebug-all-defs':

   edebug-all-defs is a variable defined in ‘edebug.el’.

   You can use the command ‘edebug-all-defs’ to toggle the value of this
   variable.  You may wish to make it local to each buffer with
   (make-local-variable 'edebug-all-defs) in your
   ‘emacs-lisp-mode-hook’.

and that's what I've apparently done.

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

Objection, your honor!

martin

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

[Lars Ingebrigtsen]

martin rudalics <rudalics@gmx.at> writes:

> No.  But I just read the doc-string of `edebug-all-defs':
>
>   edebug-all-defs is a variable defined in ‘edebug.el’.
>
>   You can use the command ‘edebug-all-defs’ to toggle the value of this
>   variable.  You may wish to make it local to each buffer with
>   (make-local-variable 'edebug-all-defs) in your
>   ‘emacs-lisp-mode-hook’.
>
> and that's what I've apparently done.
>
>> I'm leaning towards considering this a "pilot error".
>
> Objection, your honor!

Skimming this thread, it seems like this is indeed a bug...  so is the
right fix here just to reintroduce the autoloads removed by bae2cfe63c?

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

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen [2021-05-08 14:14:52] wrote:
> martin rudalics <rudalics@gmx.at> writes:
>> No.  But I just read the doc-string of `edebug-all-defs':
>>
>>   edebug-all-defs is a variable defined in ‘edebug.el’.
>>
>>   You can use the command ‘edebug-all-defs’ to toggle the value of this
>>   variable.  You may wish to make it local to each buffer with
>>   (make-local-variable 'edebug-all-defs) in your
>>   ‘emacs-lisp-mode-hook’.
>>
>> and that's what I've apparently done.
>>
>>> I'm leaning towards considering this a "pilot error".
>>
>> Objection, your honor!
>
> Skimming this thread, it seems like this is indeed a bug...  so is the
> right fix here just to reintroduce the autoloads removed by bae2cfe63c?

I think so, sadly.  I think the suggestion to put
(make-local-variable 'edebug-all-defs) is a bad one, but that boat
has sailed, apparently.


        Stefan

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

[martin rudalics]

 > I think so, sadly.  I think the suggestion to put
 > (make-local-variable 'edebug-all-defs) is a bad one, but that boat
 > has sailed, apparently.

You can still remove the suggestion.

martin

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

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Skimming this thread, it seems like this is indeed a bug...  so is the
>> right fix here just to reintroduce the autoloads removed by bae2cfe63c?
>
> I think so, sadly.  I think the suggestion to put
> (make-local-variable 'edebug-all-defs) is a bad one, but that boat
> has sailed, apparently.

OK; I've now reintroduced the autoloads, which I think should fix the
reported problem here, and I'm closing this bug report.

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