GNU bug report logs -
#47516
28.0.50; void-variable edebug-all-defs
Previous Next
Reported by: martin rudalics <rudalics <at> gmx.at>
Date: Wed, 31 Mar 2021 08:11:01 UTC
Severity: normal
Tags: fixed, moreinfo
Found in version 28.0.50
Fixed in version 28.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47516 in the body.
You can then email your comments to 47516 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47516
; Package
emacs
.
(Wed, 31 Mar 2021 08:11:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
martin rudalics <rudalics <at> gmx.at>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 31 Mar 2021 08:11:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47516
; Package
emacs
.
(Wed, 31 Mar 2021 11:17:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 47516 <at> debbugs.gnu.org (full text, mbox):
Am Mi., 31. März 2021 um 10:11 Uhr schrieb martin rudalics <rudalics <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47516
; Package
emacs
.
(Thu, 01 Apr 2021 00:05:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 47516 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47516
; Package
emacs
.
(Fri, 02 Apr 2021 03:20:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 47516 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47516
; Package
emacs
.
(Fri, 02 Apr 2021 06:50:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 47516 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47516
; Package
emacs
.
(Fri, 02 Apr 2021 13:18:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 47516 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47516
; Package
emacs
.
(Fri, 02 Apr 2021 14:17:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 47516 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47516
; Package
emacs
.
(Fri, 02 Apr 2021 15:33:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 47516 <at> debbugs.gnu.org (full text, mbox):
>> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47516
; Package
emacs
.
(Fri, 02 Apr 2021 18:25:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 47516 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47516
; Package
emacs
.
(Sat, 08 May 2021 12:16:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 47516 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> 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
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sat, 08 May 2021 12:16:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47516
; Package
emacs
.
(Sat, 08 May 2021 23:32:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 47516 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen [2021-05-08 14:14:52] wrote:
> martin rudalics <rudalics <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47516
; Package
emacs
.
(Sun, 09 May 2021 08:42:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 47516 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47516
; Package
emacs
.
(Sun, 09 May 2021 09:48:01 GMT)
Full text and
rfc822 format available.
Message #43 received at 47516 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> 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
Added tag(s) fixed.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sun, 09 May 2021 09:49:02 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 28.1, send any further explanations to
47516 <at> debbugs.gnu.org and martin rudalics <rudalics <at> gmx.at>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sun, 09 May 2021 09:49:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 06 Jun 2021 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 296 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.