GNU bug report logs -
#4631
23.1; Warnings from repeat.el
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 4631 in the body.
You can then email your comments to 4631 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#4631
; Package
emacs
.
(Sun, 04 Oct 2009 15:00:05 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Drew Adams" <drew.adams <at> oracle.com>
:
New bug report received and forwarded. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Sun, 04 Oct 2009 15:00:05 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):
emacs -Q
I have some code that looks like this:
(defun repeat-command (command)
"Repeat COMMAND."
(let ((repeat-previous-repeated-command command)
(repeat-message-function 'ignore)
(last-repeatable-command 'repeat))
(repeat nil)))
(defun foo (arg)
(interactive "P")
(repeat-command 'bar))
When I use `foo', I see these warnings in *Messages* (and briefly in
the echo area):
Warning: defvar ignored because repeat-message-function is let-bound
Warning: defvar ignored because repeat-previous-repeated-command is let-bound
Is this normal? A good idea? Avoidable?
Dunno which defvars are involved; it seems they are defvars in
`repeat.el'. Why not mention the defvar's variable in the
message, BTW?
Note: I found it difficult to try to dig deeper using the
debugger. The debugger seems useless as soon as `repeat' is involved -
it picks up debugger commands to repeat, instead.
In GNU Emacs 23.1.1 (i386-mingw-nt5.1.2600)
of 2009-07-29 on SOFT-MJASON
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4)'
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#4631
; Package
emacs
.
(Sun, 04 Oct 2009 16:55:06 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stefan Monnier <monnier <at> iro.umontreal.ca>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Sun, 04 Oct 2009 16:55:07 GMT)
Full text and
rfc822 format available.
Message #10 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):
>>>>> "Drew" == Drew Adams <drew.adams <at> oracle.com> writes:
> emacs -Q
> I have some code that looks like this:
> (defun repeat-command (command)
> "Repeat COMMAND."
> (let ((repeat-previous-repeated-command command)
> (repeat-message-function 'ignore)
> (last-repeatable-command 'repeat))
> (repeat nil)))
> (defun foo (arg)
> (interactive "P")
> (repeat-command 'bar))
> When I use `foo', I see these warnings in *Messages* (and briefly in
> the echo area):
> Warning: defvar ignored because repeat-message-function is let-bound
> Warning: defvar ignored because repeat-previous-repeated-command is let-bound
> Is this normal?
Yes: the defvar of those variable (in repeat.el) will be processed when
repeat.el is loaded, which in your case, happens when `repeat' is called
(it's loaded via autoload), i.e. at that point where you've let-bound
them, so when you get out of the let, those variables will be
incorrectly set back to unbound (i.e. the defvar will have had no effect).
> A good idea? Avoidable?
Do (require 'repeat) sometime before the let.
> Dunno which defvars are involved; it seems they are defvars in
> `repeat.el'. Why not mention the defvar's variable in the
> message, BTW?
It is mentioned.
Stefan
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#4631
; Package
emacs
.
(Sun, 04 Oct 2009 16:55:10 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stefan Monnier <monnier <at> iro.umontreal.ca>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Sun, 04 Oct 2009 16:55:10 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#4631
; Package
emacs
.
(Sun, 04 Oct 2009 19:05:07 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Drew Adams" <drew.adams <at> oracle.com>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Sun, 04 Oct 2009 19:05:07 GMT)
Full text and
rfc822 format available.
Message #20 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):
> > Is this normal?
>
> Yes: the defvar of those variable (in repeat.el) will be
> processed when
> repeat.el is loaded, which in your case, happens when
> `repeat' is called
> (it's loaded via autoload), i.e. at that point where you've let-bound
> them, so when you get out of the let, those variables will be
> incorrectly set back to unbound (i.e. the defvar will have
> had no effect).
>
> Do (require 'repeat) sometime before the let.
OK, thanks. I closed the bug.
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#4631
; Package
emacs
.
(Sun, 04 Oct 2009 19:05:14 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Drew Adams" <drew.adams <at> oracle.com>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Sun, 04 Oct 2009 19:05:14 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to "Drew Adams" <drew.adams <at> oracle.com>
Request was from
"Drew Adams" <drew.adams <at> oracle.com>
to
control <at> emacsbugs.donarmstrong.com
.
(Sun, 04 Oct 2009 19:05:22 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> emacsbugs.donarmstrong.com
.
(Mon, 02 Nov 2009 15:24:13 GMT)
Full text and
rfc822 format available.
This bug report was last modified 15 years and 316 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.