emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Change in rmail-reply


From: Stephen J. Turnbull
Subject: Re: Change in rmail-reply
Date: Fri, 30 Jan 2009 17:04:19 +0900

Richard M Stallman writes:

 > The real issue is the other people to whom the message was resent.
 > If he resends the message to address@hidden and address@hidden,
 > 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]