From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: rms@gnu.org
Cc: emacs-devel@gnu.org
Subject: Re: Change in rmail-reply
Date: Fri, 30 Jan 2009 17:04:19 +0900 [thread overview]
Message-ID: <87myd9cj98.fsf@xemacs.org> (raw)
In-Reply-To: <E1LSnl4-0002AP-C4@fencepost.gnu.org>
Richard M Stallman writes:
> The real issue is the other people to whom the message was resent.
> If he resends the message to rms@gnu.org and stephen@xemacs.org,
> and I reply, shouldn't my reply go to you?
That depends on the content of the message and his intent. I *know*
that in my own usage of reinjecting messages into the system there is
a wide variety of cases.
> Adding the other recipients to the CC list may be difficult.
That's a different issue, and how to address it depends on the needs
and expectations of Rmail users.
> With rmail-resend, the user does not edit the message. The idea is
> that all he needs to do is specify where to resend to, in the
> minibuffer, and then it goes there. Isn't that what resending is
> for?
I don't know; ask the authors/user of Rmail! What I use resend for is
when I'm moderating a mailing list or something like that. If I have
interest in the topic, I'm probably subscribed to the mailing list; if
not I don't want to be included in replies for sure.
> As for fowarding, that is no substitute, since the new header does not
> include the sender or other recipients of the original message. When
> you want to exclude them, forwarding is suitable. Otherwise, it isn't.
That's an issue with your MUA, if that is a common use case for you.
It is not a common use case for me. For example, I often forward (as
a new message) messages from emacs-devel to individual XEmacs
developers, and occasionally to the xemacs-beta list as an
informational matter. Those folks know where to find y'all if they
want to, emacs-devel has easy-to-find archives, and often the ensuing
discussion (if any) is very XEmacs-specific. I do not want to pollute
emacs-devel with off-topic conversations, so forwarding is appropriate.
In the less frequent case where I do want to widen the conversation, I
typically want to comment on the message I'm sending as well. In that
case a wide reply, adding the participants I think are appropriate to
Cc or To is my normal behavior. Very rarely I will have two mailing
lists in such a post; in those cases (except when I'm under the
influence of mind- altering substances or my evil twin personality) I
invariably use Reply-To to narrow the conversion's address list
dramatically.
I'm not claiming that your use case(s) is nonexistent or unimportant,
but I think this illustrates a wide variety of use cases where it
would be redundant or annoying if addresses were pulled from Resent-*
headers willy-nilly.
> If resending as a feature is designed for demons to send to
> intermediate addresses, and not for humans to use, what does that
> imply about rmail-resend?
I didn't say Resent-* headers were designed for daemons, I said in my
experience by far the most frequent use is by daemons. However, I use
them implicitly (ie, via a resend command) myself on a once-a-month
basis, on the occasions where a message that should go to a list gets
shunted. On those occasions I never want replies directed to me.
> Should we delete the rmail-resend command?
No. Better to rename it to something like rmail-bounce. It is useful
as-is to humans acting as mail administrators.
> Make it warn "This command has counterintuitive results, since
> replies won't go to the other recipients you resend to"?
If you don't rename the command, probably it should be documented.
I wouldn't say "counterintuitive", I would say that the resent-to
recipients will be treated like Bcc, ie, invisible to MUAs' reply
facility (and most humans).
> Make it add those recipients to the CC list as well as putting them
> in Resent-to?
No. That's redundant and its desirability is rather uncertain. A
better approach would be to provide more flexible ways to pull
addresses from various places and add them to the recipient lists.
next prev parent reply other threads:[~2009-01-30 8:04 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-26 16:30 Change in rmail-reply Richard M Stallman
2009-01-26 17:39 ` Glenn Morris
2009-01-27 6:10 ` Richard M Stallman
2009-01-27 6:44 ` Don Armstrong
2009-01-27 18:18 ` Stefan Monnier
2009-01-27 22:58 ` Richard M Stallman
2009-01-27 23:22 ` Harald Hanche-Olsen
2009-01-29 14:32 ` Richard M Stallman
2009-01-29 15:08 ` Stefan Monnier
2009-01-29 16:36 ` Stephen J. Turnbull
2009-01-30 7:25 ` Richard M Stallman
2009-01-30 8:04 ` Stephen J. Turnbull [this message]
2009-01-30 23:05 ` Richard M Stallman
2009-01-31 0:50 ` Chetan Pandya
2009-01-31 1:01 ` Chetan Pandya
2009-01-31 3:16 ` Jason Rumney
2009-01-31 3:53 ` Chetan Pandya
2009-01-31 6:32 ` Stephen J. Turnbull
2009-01-31 9:52 ` Chetan Pandya
2009-02-01 6:30 ` Richard M Stallman
2009-01-31 3:18 ` Jason Rumney
2009-01-31 3:31 ` Jason Rumney
2009-02-01 6:30 ` Richard M Stallman
2009-01-31 4:57 ` Stephen J. Turnbull
2009-01-27 23:35 ` Don Armstrong
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=87myd9cj98.fsf@xemacs.org \
--to=stephen@xemacs.org \
--cc=emacs-devel@gnu.org \
--cc=rms@gnu.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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.