From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id D9D91429E43 for ; Wed, 15 Feb 2012 16:29:22 -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 C1YaTMHmWZuS for ; Wed, 15 Feb 2012 16:29:19 -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 6C00C429E42 for ; Wed, 15 Feb 2012 16:29:19 -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 1RxpDi-0007tU-85; Thu, 16 Feb 2012 00:29:14 +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 1RxpDh-0004ff-Sn; Thu, 16 Feb 2012 00:29:10 +0000 From: Mark Walters To: Jameson Graef Rollins , notmuch@notmuchmail.org, Austin Clements Subject: Re: [RFC PATCH v5 00/11] Add NOTMUCH_MESSAGE_FLAG_EXCLUDED flag In-Reply-To: <874nurrbdb.fsf@servo.finestructure.net> References: <1329296619-7463-1-git-send-email-markwalters1009@gmail.com> <8739acrnu7.fsf@servo.finestructure.net> <8739aber9o.fsf@qmul.ac.uk> <874nurrbdb.fsf@servo.finestructure.net> User-Agent: Notmuch/0.11.1+206~g3b67774 (http://notmuchmail.org) Emacs/23.2.1 (i486-pc-linux-gnu) Date: Thu, 16 Feb 2012 00:30:35 +0000 Message-ID: <87aa4jtyac.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: 29ca7d7109ce2fa7ff2234b01ed26e28 (of first 20000 bytes) X-SpamAssassin-Score: -1.8 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.8 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.5 AWL AWL: From: address is in the auto white-list X-QM-Scan-Virus: ClamAV says the message is clean 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: Thu, 16 Feb 2012 00:29:23 -0000 On Wed, 15 Feb 2012 14:16:16 -0800, Jameson Graef Rollins wrote: > On Wed, 15 Feb 2012 21:11:15 +0000, Mark Walters wrote: > > I think the difficulty is that there are lots of annoying corner cases, > > but if there is a simpler solution that would be great! > > I think there is! > > > 1) What should notmuch show id:deleted-message-id do? > > > > It could return the thread containing the deleted message. If it does > > return a thread what subject does it assign it? Possibly it could > > return no messages and the caller would have to call it again with > > --no-exclude. > > "notmuch show id:" should always return the message > matching id: with match=true. In fact, any search that > references a specific id: should always process the message as if there > were no excludes at all. > > Excluded messages are not directly accessible at the moment, which is > definitely a bug. Adding the --no-excludes option will help, but I > still think we should just implement the behavior I outline above. > > > 2) Should notmuch search return threads which match but only in excluded > > messages? > > > > If yes then does it sort it based on match or match-not-excluded? If the > > latter what happens to threads with no match-not-excluded messages? If > > not then does searching for id:deleted-message return no results? The > > caller could try with --no-exclude, but then the caller would end up > > returning the deleted message for search id:deleted-message but not for > > search id:deleted-message or id:some-other-not-deleted-message. > > See the point above. If one of the search terms is an id: then that > message should be returned matched, as if there were no excludes. > > I think this is the right solution, for both search and show: > > - excluded messages are just match=false > > - searches that reference a specific id: are match=true no matter what > their exclude status > > - searches that reference an excluded tag are match=true > > As far as I can see this should "just work", without any existing > changes to consumers. Anyone see any issues I'm missing? So is the following what you are suggesting: always return all messages/threads that match the query whether or not the match is excluded, but only mark the message as a match if it matches and is not excluded (with some exceptions: e.g., for id: queries and tag:deleted queries). A different way of looking at this is that we revert to the old pre-exclude behaviour and then implement excludes as a "turn off the match flag" rather than the current "omit the results". That sounds plausible. But I am not sure how much simpler it is. Of my patch set patches 1-3 are essentially separate (the --no-exclude bits). I think you would need patches 4 and 5 or something similar since we both need to mark the excluded messages ("excluded" in my case, "not matched" in your case). Patch 6 could be simplified: since in your case the exclude status only matters on matching messages we have already computed it (although the exclude information would need to passed to create_thread) Patch 7: loses the exclude flag bits (5 lines or so) but the bulk is the --no-exclude for show. Patch 8 man-page stays Patch 9 (updating tests) might not be needed since the output is changing less. Patch 10 the "omit" excluded results totally option. What would you do for notmuch search --output=messages? either it outputs all matching messages or only those that match and are not excluded. The code can of course check, but things like --output=tags are more annoying as that is back into the library code. In any event I think something here is needed, and in fact any solution here would apply to either version. Patch 11: emacs would be a bit simpler in your case. However, you would need to special case the id: stuff (which could probably be done in Austin's code that examines the parsed query for tags). One possibility would be for my patch to set the match status based on match flag and not exclude flag, and separately return the whole flag-set. This might give nicer behaviour for current callers whilst giving the full information to new callers. (This email was mostly written when Austin sent his) Best wishes Mark