* to-address not known
@ 2003-10-03 8:15 Norbert Koch
2003-10-03 22:46 ` Katsumi Yamaoka
0 siblings, 1 reply; 6+ messages in thread
From: Norbert Koch @ 2003-10-03 8:15 UTC (permalink / raw)
Hi!
I've seen this now for a long time. I've a local patch for it which
is sort of a work around, but I would like to find the real cause of
this behaviour. When I do a F(ollow up) on a message, I get the
following error:
Signaling: (void-variable to-address)
gnus-post-news(nil "nnml:xemacs" [507 "Re: Use of REQUIRED in Package Creation" "Ville Skyttä <scop@xemacs.org>" "23 Jul 2003 09:25:49 +0300" "<1058941549.8025.16.camel@bobcat.mine.nu>" "<763cgz21m0.fsf@newjersey.ppllc.com> <1058814740.833.69.camel@bobcat.mine.nu> <76y8yrznr7.fsf@newjersey.ppllc.com> <1058819539.833.111.camel@bobcat.mine.nu> <76el0izpd9.fsf@newjersey.ppllc.com> <vzispun0rx.fsf@viteno.dyns.net> <1058912750.8025.9.camel@bobcat.mine.nu> <vzwue9luiv.fsf@viteno.dyns.net>" 499 18 "viteno.dyns.net xemacs:507" ((To . "Norbert Koch <viteno@xemacs.org>"))] "*Article*" (507) nil nil)
gnus-summary-followup((507) nil)
gnus-summary-followup-with-original(nil)
call-interactively(gnus-summary-followup-with-original)
recursive-edit()
byte-code("..." [print-escape-newlines print-length debugger-buffer debugger-value standard-output debugger-args pop-to-buffer erase-buffer t 50 backtrace debugger-mode re-search-forward "\n[* ] debug(" 1 debugger-reenable (lambda debug) "Entering:\n" debug backtrace-debug 3 delete-char ?* 0 exit "Return value: " prin1 ?\n ?\ error "Signaling: " "Beginning evaluation of function call form:\n" nil message "" recursive-edit buffer-read-only inhibit-trace] 3)
norbert.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: to-address not known
2003-10-03 8:15 to-address not known Norbert Koch
@ 2003-10-03 22:46 ` Katsumi Yamaoka
2003-10-06 5:19 ` Norbert Koch
0 siblings, 1 reply; 6+ messages in thread
From: Katsumi Yamaoka @ 2003-10-03 22:46 UTC (permalink / raw)
>>>>> In <vzoewy4tzl.fsf@redqueen.bytechase.cx>
>>>>> Norbert Koch <viteno@xemacs.org> wrote:
> Hi!
> I've seen this now for a long time. I've a local patch for it which
> is sort of a work around, but I would like to find the real cause of
> this behaviour. When I do a F(ollow up) on a message, I get the
> following error:
> Signaling: (void-variable to-address)
> gnus-post-news(nil "nnml:xemacs" [507 "Re: Use of REQUIRED in Package Cr...
> gnus-summary-followup((507) nil)
> gnus-summary-followup-with-original(nil)
> call-interactively(gnus-summary-followup-with-original)
I have not seen it. Could you get the backtrace again after
loading gnus-msg.el and message.el (not .elc, but .el)? Then,
the problem will be exposed in more detail.
--
Katsumi Yamaoka <yamaoka@jpl.org>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: to-address not known
2003-10-03 22:46 ` Katsumi Yamaoka
@ 2003-10-06 5:19 ` Norbert Koch
2003-10-08 16:40 ` Norbert Koch
0 siblings, 1 reply; 6+ messages in thread
From: Norbert Koch @ 2003-10-06 5:19 UTC (permalink / raw)
Cc: ding
Katsumi Yamaoka <yamaoka@jpl.org> writes:
> I have not seen it. Could you get the backtrace again after
> loading gnus-msg.el and message.el (not .elc, but .el)? Then,
> the problem will be exposed in more detail.
Hrmpf, when I load these two files, I can't reproduce the error :-/
I don't think it's a byte-compiler issue, though.
I try to get a better backtrace.
norbert.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: to-address not known
2003-10-06 5:19 ` Norbert Koch
@ 2003-10-08 16:40 ` Norbert Koch
2003-10-09 8:22 ` Katsumi Yamaoka
0 siblings, 1 reply; 6+ messages in thread
From: Norbert Koch @ 2003-10-08 16:40 UTC (permalink / raw)
Cc: ding
Norbert Koch <viteno@xemacs.org> writes:
> Hrmpf, when I load these two files, I can't reproduce the error :-/
> I don't think it's a byte-compiler issue, though.
>
> I try to get a better backtrace.
Here we go. Must have had the fixed version in the path the last time
around. Is this any better?
Thanks,
norbert.
Signaling: (void-variable to-address)
(message-wide-reply to-address)
(if post (progn (message-mail ...) (when ... ...)) (set-buffer gnus-article-copy) (gnus-msg-treat-broken-reply-to) (message-wide-reply to-address))
(if (or (and to-group ...) newsgroup-p force-news (and ... ... ... ...)) (if post (message-news ...) (set-buffer gnus-article-copy) (gnus-msg-treat-broken-reply-to) (message-followup ...)) (if post (progn ... ...) (set-buffer gnus-article-copy) (gnus-msg-treat-broken-reply-to) (message-wide-reply to-address)))
(let* ((group ...) (charset ...) (pgroup group) to-address to-group mailing-list to-list newsgroup-p) (when group (setq to-address ... to-group ... to-list ... newsgroup-p ... mailing-list ... group ...)) (if (or ... newsgroup-p force-news ...) (if post ... ... ... ...) (if post ... ... ... ...)) (when yank (gnus-inews-yank-articles yank)))
(progn (let* (... ... ... to-address to-group mailing-list to-list newsgroup-p) (when group ...) (if ... ... ...) (when yank ...)))
(unwind-protect (progn (let* ... ... ... ...)) (gnus-inews-add-send-actions gnus-setup-message-winconf gnus-setup-message-buffer gnus-setup-message-article (cond ... ... ...) gnus-setup-yanked-articles) (setq gnus-message-buffer (current-buffer)) (set (make-local-variable ...) (cons gnus-setup-message-group gnus-setup-message-article)) (set (make-local-variable ...) gnus-setup-message-group) (gnus-run-hooks (quote gnus-message-setup-hook)) (if (eq major-mode ...) (let ... ... ... ... ... ... ...) (mml-destroy-buffers) (setq mml-buffer-list mbl)))
(let ((gnus-setup-message-winconf ...) (gnus-setup-message-buffer ...) (gnus-setup-message-article gnus-article-reply) (gnus-setup-yanked-articles gnus-article-yanked-articles) (gnus-setup-message-group gnus-newsgroup-name) (message-header-setup-hook ...) (mbl mml-buffer-list) (message-mode-hook ...)) (setq mml-buffer-list nil) (add-hook (quote message-header-setup-hook) (quote gnus-inews-insert-gcc)) (add-hook (quote message-header-setup-hook) (quote gnus-inews-insert-archive-gcc)) (add-hook (quote message-mode-hook) (lambda nil ...)) (gnus-pull (quote X-Draft-From) message-required-headers) (when (and gnus-setup-message-group ...) (push ... message-required-headers)) (unwind-protect (progn ...) (gnus-inews-add-send-actions gnus-setup-message-winconf gnus-setup-message-buffer gnus-setup-message-article ... gnus-setup-yanked-articles) (setq gnus-message-buffer ...) (set ... ...) (set ... gnus-setup-message-group) (gnus-run-hooks ...) (if ... ... ... ...)) (message-hide-headers) (gnus-add-buffer) (gnus-configure-windows (cond ... ... ...) t) (run-hooks (quote post-command-hook)) (set-buffer-modified-p nil))
(gnus-setup-message (cond (yank ...) (article-buffer ...) (t ...)) (let* (... ... ... to-address to-group mailing-list to-list newsgroup-p) (when group ...) (if ... ... ...) (when yank ...)))
(let ((gnus-article-reply ...) (gnus-article-yanked-articles yank) (add-to-list gnus-add-to-list)) (gnus-setup-message (cond ... ... ...) (let* ... ... ... ...)))
gnus-post-news(nil "nnml:lfnet" [9709 "exim-filter in Abhaengigkeit von Spam-Level" "Frank Heydlauf <fh@LF.net>" "Wed, 8 Oct 2003 16:53:32 +0200" "<20031008145332.GE98065@velo.LF.net>" "" 532 21 "redqueen.bytechase.cx lfnet:9709" ((To . "exim@LF.net, Christian Recktenwald <chris@LF.net>") (X-Ticket-Nr . "LFN16051712"))] "*Article*" (9709) nil nil)
(let ((headers ...) (gnus-newsgroup-name gnus-newsgroup-name)) (gnus-post-news nil gnus-newsgroup-name headers gnus-article-buffer yank nil force-news) (gnus-summary-handle-replysign))
gnus-summary-followup((9709) nil)
gnus-summary-followup-with-original(nil)
call-interactively(gnus-summary-followup-with-original)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: to-address not known
2003-10-08 16:40 ` Norbert Koch
@ 2003-10-09 8:22 ` Katsumi Yamaoka
2003-10-09 9:07 ` Norbert Koch
0 siblings, 1 reply; 6+ messages in thread
From: Katsumi Yamaoka @ 2003-10-09 8:22 UTC (permalink / raw)
Cc: ding
[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]
>>>>> In <vzpth7k7iz.fsf@redqueen.bytechase.cx>
>>>>> Norbert Koch <viteno@xemacs.org> wrote:
> Here we go. Must have had the fixed version in the path the last time
> around. Is this any better?
> Thanks,
> norbert.
That's perfect. Thank you.
> Signaling: (void-variable to-address)
> (message-wide-reply to-address)
It happened in the " *gnus article copy*" buffer. Just before
it, to-address was surely bound by `let*' in the summary buffer.
[...]
> (let* ((group ...) (charset ...) (pgroup group) to-address ...
[...]
> (gnus-setup-message (cond (yank ...) (article-buffer ...) (...
[...]
> gnus-post-news(nil "nnml:lfnet" [9709 "exim-filter in Abhae...
[...]
> gnus-summary-followup((9709) nil)
> gnus-summary-followup-with-original(nil)
> call-interactively(gnus-summary-followup-with-original)
I have only one idea for the reason it occurs. It is that the
to-address buffer-local variable exists only in the summary
buffer. I don't know which function puts it there. By
evaluating the following form in the summary buffer when an
error has occurred, you can see if it is true or not:
(local-variable-p 'to-address (current-buffer))
If it returns t, it may be better to grep all your files (except
for the Gnus sources) for "to-address". :p
Though it is just a workaround, here is a patch for the problem:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 548 bytes --]
--- gnus-msg.el~ 2003-09-17 21:51:59 +0000
+++ gnus-msg.el 2003-10-09 08:17:57 +0000
@@ -944,9 +944,10 @@
add-to-list)
(push (list 'gnus-inews-add-to-address pgroup)
message-send-actions)))
- (set-buffer gnus-article-copy)
- (gnus-msg-treat-broken-reply-to)
- (message-wide-reply to-address)))
+ (let ((real-to-address to-address))
+ (set-buffer gnus-article-copy)
+ (gnus-msg-treat-broken-reply-to)
+ (message-wide-reply real-to-address))))
(when yank
(gnus-inews-yank-articles yank))))))
[-- Attachment #3: Type: text/plain, Size: 183 bytes --]
By the way, I found a strange behavior about the
make-local-variable function in XEmacs 21.4/5. I will report it
to the XEmacs-beta list later.
--
Katsumi Yamaoka <yamaoka@jpl.org>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: to-address not known
2003-10-09 8:22 ` Katsumi Yamaoka
@ 2003-10-09 9:07 ` Norbert Koch
0 siblings, 0 replies; 6+ messages in thread
From: Norbert Koch @ 2003-10-09 9:07 UTC (permalink / raw)
Cc: ding
Katsumi Yamaoka <yamaoka@jpl.org> writes:
> I have only one idea for the reason it occurs. It is that the
> to-address buffer-local variable exists only in the summary
> buffer. I don't know which function puts it there. By
> evaluating the following form in the summary buffer when an
> error has occurred, you can see if it is true or not:
>
> (local-variable-p 'to-address (current-buffer))
Yes, I also think, this is the problem.
> If it returns t, it may be better to grep all your files (except
> for the Gnus sources) for "to-address". :p
Uh, oh :-) At least it's worth a shot.
> Though it is just a workaround, here is a patch for the problem:
[...]
That's equivalent to the patch I currently use :-)
> By the way, I found a strange behavior about the
> make-local-variable function in XEmacs 21.4/5. I will report it
> to the XEmacs-beta list later.
Great, thanks.
norbert.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-10-09 9:07 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-03 8:15 to-address not known Norbert Koch
2003-10-03 22:46 ` Katsumi Yamaoka
2003-10-06 5:19 ` Norbert Koch
2003-10-08 16:40 ` Norbert Koch
2003-10-09 8:22 ` Katsumi Yamaoka
2003-10-09 9:07 ` Norbert Koch
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).