Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 3A5CC431FD0 for ; Mon, 9 Jan 2012 03:13:47 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+wciQ0hRaxt for ; Mon, 9 Jan 2012 03:13:46 -0800 (PST) Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id A3998431FB6 for ; Mon, 9 Jan 2012 03:13:46 -0800 (PST) Received: from smtp.qmul.ac.uk ([138.37.6.40]) by mail2.qmul.ac.uk with esmtp (Exim 4.71) (envelope-from ) id 1RkDAc-0005RO-6T; Mon, 09 Jan 2012 11:13:42 +0000 Received: from 94-192-233-223.zone6.bethere.co.uk ([94.192.233.223] helo=localhost) by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RkDAc-0004dc-03; Mon, 09 Jan 2012 11:13:42 +0000 From: Mark Walters To: Jani Nikula Subject: Re: [PATCH v2 3/6] cli: add support for replying just to the sender in "notmuch reply" In-Reply-To: <87ehv9jjqy.fsf@nikula.org> References: <6e37e058190d7c06519de3e67569fbee0be45461.1326058946.git.jani@nikula.org> <877h11eq3g.fsf@qmul.ac.uk> <87ehv9jjqy.fsf@nikula.org> User-Agent: Notmuch/0.10.2+172~g60f099b (http://notmuchmail.org) Emacs/23.3.1 (i486-pc-linux-gnu) Date: Mon, 09 Jan 2012 11:13:41 +0000 Message-ID: <87zkdxf7ru.fsf@qmul.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender-Host-Address: 94.192.233.223 X-QM-SPAM-Info: Sender has good ham record. :) X-QM-Body-MD5: 9d09da13116d1e289f72676ceee20276 (of first 20000 bytes) X-SpamAssassin-Score: -1.7 X-SpamAssassin-SpamBar: - X-SpamAssassin-Report: The QM spam filters have analysed this message to determine if it is spam. We require at least 5.0 points to mark a message as spam. This message scored -1.7 points. Summary of the scoring: * -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, * medium trust * [138.37.6.40 listed in list.dnswl.org] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (markwalters1009[at]gmail.com) * -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay * domain * 0.6 AWL AWL: From: address is in the auto white-list X-QM-Scan-Virus: ClamAV says the message is clean Cc: notmuch@notmuchmail.org X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 11:13:47 -0000 > > The reply-to-thread is a rare case anyway, regardless of reply-to-all or > reply-to-sender, and even the current implementation does not gather all > the recipients from all the messages. Try it out, it seems to me it does > not quite do what you think it does. > > IMHO it should use oldest-first rather than newest-first sort order, and > I guess it should really go through the messages being replied to and > get the recipients from all of them. It's just out of scope for this > patch set to fix these. But if that gets fixed later, I would like the > reply-to-sender for multiple messages follow the logic of single-reply, > just with all the addresses put together. I completely agree it's a rare case. Having tried the code (yours and the original) it seems to be very strange: In its current form it seems to be reply to people on newest message in thread and include all the bodies with some spurious headers mixed in. So your code is reply-to-sender applied to people on newest message in thread, and include all the bodies with some slightly different spurious headers mixed in. I like your suggested solution. Anyway it's a rare case; the current code is odd and yours is no odder so I agree with leaving it for a later patch (if anyone cares enough!). Best wishes Mark