39/9c2a38718abacf6f9d534b35854dc528d03e10

   1 Return-Path: <m.walters@qmul.ac.uk>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id D9D91429E43\r
   6         for <notmuch@notmuchmail.org>; Wed, 15 Feb 2012 16:29:22 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -1.098\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5\r
  12         tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001,\r
  13         NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id C1YaTMHmWZuS for <notmuch@notmuchmail.org>;\r
  17         Wed, 15 Feb 2012 16:29:19 -0800 (PST)\r
  18 Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6])\r
  19         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
  20         (No client certificate requested)\r
  21         by olra.theworths.org (Postfix) with ESMTPS id 6C00C429E42\r
  22         for <notmuch@notmuchmail.org>; Wed, 15 Feb 2012 16:29:19 -0800 (PST)\r
  23 Received: from smtp.qmul.ac.uk ([138.37.6.40])\r
  24         by mail2.qmul.ac.uk with esmtp (Exim 4.71)\r
  25         (envelope-from <m.walters@qmul.ac.uk>)\r
  26         id 1RxpDi-0007tU-85; Thu, 16 Feb 2012 00:29:14 +0000\r
  27 Received: from 94-192-233-223.zone6.bethere.co.uk ([94.192.233.223]\r
  28         helo=localhost)\r
  29         by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69)\r
  30         (envelope-from <m.walters@qmul.ac.uk>)\r
  31         id 1RxpDh-0004ff-Sn; Thu, 16 Feb 2012 00:29:10 +0000\r
  32 From: Mark Walters <markwalters1009@gmail.com>\r
  33 To: Jameson Graef Rollins <jrollins@finestructure.net>,\r
  34  notmuch@notmuchmail.org,       Austin Clements <amdragon@mit.edu>\r
  35 Subject: Re: [RFC PATCH v5 00/11] Add NOTMUCH_MESSAGE_FLAG_EXCLUDED flag\r
  36 In-Reply-To: <874nurrbdb.fsf@servo.finestructure.net>\r
  37 References: <1329296619-7463-1-git-send-email-markwalters1009@gmail.com>\r
  38         <8739acrnu7.fsf@servo.finestructure.net>\r
  39         <8739aber9o.fsf@qmul.ac.uk>\r
  40         <874nurrbdb.fsf@servo.finestructure.net>\r
  41 User-Agent: Notmuch/0.11.1+206~g3b67774 (http://notmuchmail.org) Emacs/23.2.1\r
  42         (i486-pc-linux-gnu)\r
  43 Date: Thu, 16 Feb 2012 00:30:35 +0000\r
  44 Message-ID: <87aa4jtyac.fsf@qmul.ac.uk>\r
  45 MIME-Version: 1.0\r
  46 Content-Type: text/plain; charset=us-ascii\r
  47 X-Sender-Host-Address: 94.192.233.223\r
  48 X-QM-SPAM-Info: Sender has good ham record.  :)\r
  49 X-QM-Body-MD5: 29ca7d7109ce2fa7ff2234b01ed26e28 (of first 20000 bytes)\r
  50 X-SpamAssassin-Score: -1.8\r
  51 X-SpamAssassin-SpamBar: -\r
  52 X-SpamAssassin-Report: The QM spam filters have analysed this message to\r
  53         determine if it is\r
  54         spam. We require at least 5.0 points to mark a message as spam.\r
  55         This message scored -1.8 points.\r
  56         Summary of the scoring: \r
  57         * -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/,\r
  58         *      medium trust\r
  59         *      [138.37.6.40 listed in list.dnswl.org]\r
  60         * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\r
  61         provider *      (markwalters1009[at]gmail.com)\r
  62         * -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay\r
  63         *      domain\r
  64         *  0.5 AWL AWL: From: address is in the auto white-list\r
  65 X-QM-Scan-Virus: ClamAV says the message is clean\r
  66 X-BeenThere: notmuch@notmuchmail.org\r
  67 X-Mailman-Version: 2.1.13\r
  68 Precedence: list\r
  69 List-Id: "Use and development of the notmuch mail system."\r
  70         <notmuch.notmuchmail.org>\r
  71 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  72         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  73 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  74 List-Post: <mailto:notmuch@notmuchmail.org>\r
  75 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  76 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  77         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  78 X-List-Received-Date: Thu, 16 Feb 2012 00:29:23 -0000\r
  79 \r
  80 On Wed, 15 Feb 2012 14:16:16 -0800, Jameson Graef Rollins <jrollins@finestructure.net> wrote:\r
  81 > On Wed, 15 Feb 2012 21:11:15 +0000, Mark Walters <markwalters1009@gmail.com> wrote:\r
  82 > > I think the difficulty is that there are lots of annoying corner cases,\r
  83 > > but if there is a  simpler solution that would be great!\r
  84 > \r
  85 > I think there is!\r
  86 > \r
  87 > > 1) What should notmuch show id:deleted-message-id do? \r
  88 > > \r
  89 > > It could return the thread containing the deleted message. If it does\r
  90 > > return a thread what subject does it assign it?  Possibly it could\r
  91 > > return no messages and the caller would have to call it again with\r
  92 > > --no-exclude.\r
  93 > \r
  94 > "notmuch show id:<excluded-id>" should always return the message\r
  95 > matching id:<excluded-id> with match=true.  In fact, any search that\r
  96 > references a specific id: should always process the message as if there\r
  97 > were no excludes at all.\r
  98 > \r
  99 > Excluded messages are not directly accessible at the moment, which is\r
 100 > definitely a bug.  Adding the --no-excludes option will help, but I\r
 101 > still think we should just implement the behavior I outline above.\r
 102 > \r
 103 > > 2) Should notmuch search return threads which match but only in excluded\r
 104 > > messages? \r
 105 > > \r
 106 > > If yes then does it sort it based on match or match-not-excluded? If the\r
 107 > > latter what happens to threads with no match-not-excluded messages? If\r
 108 > > not then does searching for id:deleted-message return no results? The\r
 109 > > caller could try with --no-exclude, but then the caller would end up\r
 110 > > returning the deleted message for search id:deleted-message but not for\r
 111 > > search id:deleted-message or id:some-other-not-deleted-message.\r
 112 > \r
 113 > See the point above.  If one of the search terms is an id: then that\r
 114 > message should be returned matched, as if there were no excludes.\r
 115 > \r
 116 > I think this is the right solution, for both search and show:\r
 117 > \r
 118 > - excluded messages are just match=false\r
 119 > \r
 120 > - searches that reference a specific id: are match=true no matter what\r
 121 >   their exclude status\r
 122 > \r
 123 > - searches that reference an excluded tag are match=true\r
 124 > \r
 125 > As far as I can see this should "just work", without any existing\r
 126 > changes to consumers.  Anyone see any issues I'm missing?\r
 127 \r
 128 So is the following what you are suggesting:\r
 129 \r
 130 always return all messages/threads that match the query whether or not\r
 131 the match is excluded, but only mark the message as a match if it\r
 132 matches and is not excluded (with some exceptions: e.g., for id: queries\r
 133 and tag:deleted queries).\r
 134 \r
 135 A different way of looking at this is that we revert to the old\r
 136 pre-exclude behaviour and then implement excludes as a "turn off the\r
 137 match flag" rather than the current "omit the results".\r
 138 \r
 139 That sounds plausible. \r
 140 \r
 141 But I am not sure how much simpler it is. Of my patch set patches 1-3\r
 142 are essentially separate (the --no-exclude bits). \r
 143 \r
 144 I think you would need patches 4 and 5 or something similar since we\r
 145 both need to mark the excluded messages ("excluded" in my case, "not\r
 146 matched" in your case).\r
 147 \r
 148 Patch 6 could be simplified: since in your case the exclude status only\r
 149 matters on matching messages we have already computed it (although the\r
 150 exclude information would need to passed to create_thread)\r
 151 \r
 152 Patch 7: loses the exclude flag bits (5 lines or so) but the bulk is the\r
 153 --no-exclude for show.\r
 154 \r
 155 Patch 8 man-page stays\r
 156 \r
 157 Patch 9 (updating tests) might not be needed since the output is\r
 158 changing less.\r
 159 \r
 160 Patch 10 the "omit" excluded results totally option. What would you do\r
 161 for notmuch search --output=messages? either it outputs all matching\r
 162 messages or only those that match and are not excluded. The code can of\r
 163 course check, but things like --output=tags are more annoying as that is\r
 164 back into the library code. In any event I think something here is\r
 165 needed, and in fact any solution here would apply to either version.\r
 166 \r
 167 Patch 11: emacs would be a bit simpler in your case.\r
 168 \r
 169 However, you would need to special case the id: stuff (which could\r
 170 probably be done in Austin's code that examines the parsed query for\r
 171 tags). \r
 172 \r
 173 \r
 174 One possibility would be for my patch to set the match status based on\r
 175 match flag and not exclude flag, and separately return the whole\r
 176 flag-set. This might give nicer behaviour for current callers whilst\r
 177 giving the full information to new callers.\r
 178 \r
 179 (This email was mostly written when Austin sent his)\r
 180 \r
 181 Best wishes\r
 182 \r
 183 Mark\r