From: Katsumi Yamaoka <yamaoka@jpl.org>
Cc: ding@gnus.org
Subject: Re: to-address not known
Date: Thu, 09 Oct 2003 17:22:19 +0900 [thread overview]
Message-ID: <b9yy8vuhlc4.fsf@jpl.org> (raw)
In-Reply-To: <vzpth7k7iz.fsf@redqueen.bytechase.cx>
[-- 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>
next prev parent reply other threads:[~2003-10-09 8:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-03 8:15 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 [this message]
2003-10-09 9:07 ` Norbert Koch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b9yy8vuhlc4.fsf@jpl.org \
--to=yamaoka@jpl.org \
--cc=ding@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).