From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Change in rmail-reply Date: Fri, 30 Jan 2009 17:04:19 +0900 Message-ID: <87myd9cj98.fsf@xemacs.org> References: <874ozidq89.fsf@xemacs.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1233302738 12268 80.91.229.12 (30 Jan 2009 08:05:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 30 Jan 2009 08:05:38 +0000 (UTC) Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 30 09:06:51 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LSoOo-00055B-Ip for ged-emacs-devel@m.gmane.org; Fri, 30 Jan 2009 09:06:51 +0100 Original-Received: from localhost ([127.0.0.1]:53604 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LSoNW-0001UF-6x for ged-emacs-devel@m.gmane.org; Fri, 30 Jan 2009 03:05:30 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LSoNS-0001TO-3x for emacs-devel@gnu.org; Fri, 30 Jan 2009 03:05:26 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LSoNR-0001St-IJ for emacs-devel@gnu.org; Fri, 30 Jan 2009 03:05:25 -0500 Original-Received: from [199.232.76.173] (port=46277 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LSoNR-0001Sg-Ee for emacs-devel@gnu.org; Fri, 30 Jan 2009 03:05:25 -0500 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:35185) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LSoNP-0003PN-E7; Fri, 30 Jan 2009 03:05:23 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id D1475820E; Fri, 30 Jan 2009 17:05:15 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 960AD1A4AFD; Fri, 30 Jan 2009 17:04:20 +0900 (JST) In-Reply-To: X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta28) "fuki" 83e35df20028+ XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:108390 Archived-At: 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.