--- /dev/null
+Return-Path: <m.walters@qmul.ac.uk>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id 9E665429E54\r
+ for <notmuch@notmuchmail.org>; Sun, 22 Jan 2012 10:46:53 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -1.098\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5\r
+ tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001,\r
+ NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id fhymNktiTkJr for <notmuch@notmuchmail.org>;\r
+ Sun, 22 Jan 2012 10:46:53 -0800 (PST)\r
+Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6])\r
+ (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
+ (No client certificate requested)\r
+ by olra.theworths.org (Postfix) with ESMTPS id B7DB6429E40\r
+ for <notmuch@notmuchmail.org>; Sun, 22 Jan 2012 10:46:52 -0800 (PST)\r
+Received: from smtp.qmul.ac.uk ([138.37.6.40])\r
+ by mail2.qmul.ac.uk with esmtp (Exim 4.71)\r
+ (envelope-from <m.walters@qmul.ac.uk>)\r
+ id 1Rp2RD-0005b4-IE; Sun, 22 Jan 2012 18:46:47 +0000\r
+Received: from 94-192-233-223.zone6.bethere.co.uk ([94.192.233.223]\r
+ helo=localhost)\r
+ by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69)\r
+ (envelope-from <m.walters@qmul.ac.uk>)\r
+ id 1Rp2RD-0004MT-7V; Sun, 22 Jan 2012 18:46:47 +0000\r
+From: Mark Walters <markwalters1009@gmail.com>\r
+To: Austin Clements <amdragon@MIT.EDU>\r
+Subject: Re: [PATCH] Automatically exclude tags in notmuch-show\r
+In-Reply-To: <20120122181609.GQ16740@mit.edu>\r
+References: <874nvric7c.fsf@qmul.ac.uk>\r
+ <1327010583-23954-1-git-send-email-markwalters1009@gmail.com>\r
+ <20120119225910.GT16740@mit.edu> <871uqvgrnm.fsf@qmul.ac.uk>\r
+ <20120120171801.GA16740@mit.edu> <20120122181609.GQ16740@mit.edu>\r
+User-Agent: Notmuch/0.11+77~gad6d0d5 (http://notmuchmail.org) Emacs/23.2.1\r
+ (i486-pc-linux-gnu)\r
+Date: Sun, 22 Jan 2012 18:47:43 +0000\r
+Message-ID: <87d3abing0.fsf@qmul.ac.uk>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+X-Sender-Host-Address: 94.192.233.223\r
+X-QM-SPAM-Info: Sender has good ham record. :)\r
+X-QM-Body-MD5: a39b6fe74443b40cf97eefdc497e27ba (of first 20000 bytes)\r
+X-SpamAssassin-Score: -1.8\r
+X-SpamAssassin-SpamBar: -\r
+X-SpamAssassin-Report: The QM spam filters have analysed this message to\r
+ determine if it is\r
+ spam. We require at least 5.0 points to mark a message as spam.\r
+ This message scored -1.8 points.\r
+ Summary of the scoring: \r
+ * -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/,\r
+ * medium trust\r
+ * [138.37.6.40 listed in list.dnswl.org]\r
+ * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\r
+ provider * (markwalters1009[at]gmail.com)\r
+ * -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay\r
+ * domain\r
+ * 0.5 AWL AWL: From: address is in the auto white-list\r
+X-QM-Scan-Virus: ClamAV says the message is clean\r
+Cc: notmuch@notmuchmail.org\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Sun, 22 Jan 2012 18:46:53 -0000\r
+\r
+\r
+On Sun, 22 Jan 2012 13:16:09 -0500, Austin Clements <amdragon@MIT.EDU> wrote:\r
+> Quoth myself on Jan 20 at 12:18 pm:\r
+> > Quoth Mark Walters on Jan 20 at 12:10 am:\r
+> > > \r
+> > > Ok Having said this is trivial I have found a problem. What should\r
+> > > notmuch do if you do something like\r
+> > > \r
+> > > notmuch show id:<some-id>\r
+> > > and that message is marked with a deleted tag? To be consistent with the\r
+> > > other cases (where a deleted message is in a matched thread) we might\r
+> > > want to return the message with the not-matched flag set (eg in\r
+> > > JSON). But my patch doesn't, as it never even sees the thread since it\r
+> > > doesn't match.\r
+> > > \r
+> > > Looking at notmuch-show.c I think we should not apply the exclude tags\r
+> > > to do_show_single, but usually should apply it to do_show. One solution\r
+> > > which is simple and is at least close to right would be to get do_show\r
+> > > to return the number of threads found. If this is zero then retry the\r
+> > > query without the excludes (possible setting the match_flag to zero on\r
+> > > each message since we know it does not match)\r
+> > > \r
+> > > This is not a completely correct solution as if you ask notmuch-show to\r
+> > > show more than one thread it might threads which only contain deleted\r
+> > > messages.\r
+> > > \r
+> > > I can't see other good possibilities without slowing down the normal\r
+> > > path a lot (eg find all threads that match the original query and then\r
+> > > apply the argument above).\r
+> > > \r
+> > > Any thoughts?\r
+> > \r
+> > Oh dear.\r
+> > \r
+> > Well, here's one idea. Instead of doing a single thread query in\r
+> > show, do a thread query without the exclusions and then a message\r
+> > query with the exclusions. Output all of the messages from the first\r
+> > query, but use the results of the second query to determine which\r
+> > messages are "matched". The same could be accomplished in the library\r
+> > somewhat more efficiently, but it's not obvious to me what the API\r
+> > would be.\r
+> \r
+> Here's a slightly crazier idea that's more library-invasive than the\r
+> original approach, but probably better in the long run.\r
+> \r
+> Have notmuch_query_search_* return everything and make exclusion a\r
+> message flag like NOTMUCH_MESSAGE_FLAG_MATCH. Tweak the definition of\r
+> "matched" to mean "matched and not excluded" (specifically, a message\r
+> would have the match flag or the excluded flag or neither, but not\r
+> both). Search would skip threads with zero matched messages and I\r
+> think show would Just Work.\r
+> \r
+> I can think of two ways to implement this. notmuch_query_search_*\r
+> could perform both the original query and the query with exclusions\r
+> and use the docid set from the second to compute the "excluded"\r
+> message flag. Alternatively, it could examine the tags of each\r
+> message directly to compute the flag. The latter is probably easier\r
+> to implement, but probably slower.\r
+\r
+I really like the idea of returning two flags. I think your first\r
+suggestion works better for sorting reasons: we want to return a thread\r
+which has a match-not-excluded message and also a match-excluded message\r
+to be sorted based on the match-not-excluded message. Hence in\r
+notmuch_query_search_threads we can create the list of docids to iterate\r
+over as the list generated by query with exclusions followed by the list\r
+without exclusions. This list contains lots of messages twice but that\r
+doesn't matter since we have to check whether we have already output\r
+the message in an earlier thread anyway. \r
+\r
+Incidentally, it might not take very much more code to allow\r
+notmuch_query_search_threads to take two arbitrary queries and return\r
+all threads which match the first case but mark as matched those that\r
+match the second: i.e. a step on the way towards "thread based and".\r
+\r
+Best wishes\r
+\r
+Mark\r
+\r
+\r
projects / notmuch-archives.git / commitdiff