Re: [RFC PATCH v5 00/11] Add NOTMUCH_MESSAGE_FLAG_EXCLUDED flag

diff --git a/54/30a46db702c138972091da21053820690d528c b/54/30a46db702c138972091da21053820690d528c
new file mode 100644 (file)
index 0000000..7b1667f
--- /dev/null
+++ b/54/30a46db702c138972091da21053820690d528c
@@ -0,0 +1,132 @@
+Return-Path: <jrollins@finestructure.net>\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 1A7E6431E82\r
+       for <notmuch@notmuchmail.org>; Wed, 15 Feb 2012 14:16:25 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -2.29\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5\r
+       tests=[RCVD_IN_DNSWL_MED=-2.3, T_MIME_NO_TEXT=0.01] 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 Nxdm0KQLPXyc for <notmuch@notmuchmail.org>;\r
+       Wed, 15 Feb 2012 14:16:23 -0800 (PST)\r
+Received: from outgoing-mail.its.caltech.edu (outgoing-mail.its.caltech.edu\r
+       [131.215.239.19])\r
+       by olra.theworths.org (Postfix) with ESMTP id EB2A8431E62\r
+       for <notmuch@notmuchmail.org>; Wed, 15 Feb 2012 14:16:22 -0800 (PST)\r
+Received: from fire-doxen.imss.caltech.edu (localhost [127.0.0.1])\r
+       by fire-doxen-postvirus (Postfix) with ESMTP id 29EBB328064;\r
+       Wed, 15 Feb 2012 14:16:22 -0800 (PST)\r
+X-Spam-Scanned: at Caltech-IMSS on fire-doxen by amavisd-new\r
+Received: from finestructure.net (DHCP-123-180.caltech.edu [131.215.123.180])\r
+       (Authenticated sender: jrollins)\r
+       by fire-doxen-submit (Postfix) with ESMTP id 5100F2E50D9A;\r
+       Wed, 15 Feb 2012 14:16:19 -0800 (PST)\r
+Received: by finestructure.net (Postfix, from userid 1000)\r
+       id F20A84D3; Wed, 15 Feb 2012 14:16:18 -0800 (PST)\r
+From: Jameson Graef Rollins <jrollins@finestructure.net>\r
+To: Mark Walters <markwalters1009@gmail.com>, notmuch@notmuchmail.org\r
+Subject: Re: [RFC PATCH v5 00/11] Add NOTMUCH_MESSAGE_FLAG_EXCLUDED flag\r
+In-Reply-To: <8739aber9o.fsf@qmul.ac.uk>\r
+References: <1329296619-7463-1-git-send-email-markwalters1009@gmail.com>\r
+       <8739acrnu7.fsf@servo.finestructure.net>\r
+       <8739aber9o.fsf@qmul.ac.uk>\r
+User-Agent: Notmuch/0.11.1+192~g2bb5859 (http://notmuchmail.org) Emacs/23.3.1\r
+       (x86_64-pc-linux-gnu)\r
+Date: Wed, 15 Feb 2012 14:16:16 -0800\r
+Message-ID: <874nurrbdb.fsf@servo.finestructure.net>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+       micalg=pgp-sha256; protocol="application/pgp-signature"\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: Wed, 15 Feb 2012 22:16:25 -0000\r
+\r
+--=-=-=\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+On Wed, 15 Feb 2012 21:11:15 +0000, Mark Walters <markwalters1009@gmail.com=\r
+> wrote:\r
+> I think the difficulty is that there are lots of annoying corner cases,\r
+> but if there is a  simpler solution that would be great!\r
+\r
+I think there is!\r
+\r
+> 1) What should notmuch show id:deleted-message-id do?=20\r
+>=20\r
+> It could return the thread containing the deleted message. If it does\r
+> return a thread what subject does it assign it?  Possibly it could\r
+> return no messages and the caller would have to call it again with\r
+> --no-exclude.\r
+\r
+"notmuch show id:<excluded-id>" should always return the message\r
+matching id:<excluded-id> with match=3Dtrue.  In fact, any search that\r
+references a specific id: should always process the message as if there\r
+were no excludes at all.\r
+\r
+Excluded messages are not directly accessible at the moment, which is\r
+definitely a bug.  Adding the --no-excludes option will help, but I\r
+still think we should just implement the behavior I outline above.\r
+\r
+> 2) Should notmuch search return threads which match but only in excluded\r
+> messages?=20\r
+>=20\r
+> If yes then does it sort it based on match or match-not-excluded? If the\r
+> latter what happens to threads with no match-not-excluded messages? If\r
+> not then does searching for id:deleted-message return no results? The\r
+> caller could try with --no-exclude, but then the caller would end up\r
+> returning the deleted message for search id:deleted-message but not for\r
+> search id:deleted-message or id:some-other-not-deleted-message.\r
+\r
+See the point above.  If one of the search terms is an id: then that\r
+message should be returned matched, as if there were no excludes.\r
+\r
+I think this is the right solution, for both search and show:\r
+\r
+=2D excluded messages are just match=3Dfalse\r
+\r
+=2D searches that reference a specific id: are match=3Dtrue no matter what\r
+  their exclude status\r
+\r
+=2D searches that reference an excluded tag are match=3Dtrue\r
+\r
+As far as I can see this should "just work", without any existing\r
+changes to consumers.  Anyone see any issues I'm missing?\r
+\r
+jamie.\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.11 (GNU/Linux)\r
+\r
+iQIcBAEBCAAGBQJPPC6wAAoJEO00zqvie6q82KAP/iS+8YA2Rg12NNcjQvFLgRMi\r
+Uv6Fhd8tcbaRNASitOigUXVutWdzZMxiteOAOxo+4king614l+7dek/Cv0aChozT\r
+bZtkhKmIv4jZPuyWm2kOpmULxJY+ehsQ74jmq7UOoxEyZtytEbLI7HSWPCe9LFAX\r
+vdq5SC1fTNopxfdxpF9D5XCiIm6/T5gdT/moCa+BuhvFu/qOJ6UA4AZ7CiM9YbBV\r
+ndr/fW203wY6CpUdHnI9XXvcQTF03FKrFKkvaSWlHOxlwO+wOxsWf4glEVPMn/4L\r
+w9hlu+4qM7LbB7Iolxc0B6UNo8mHZz/XDerC7kaHOSO3H6+xVH40QCR0kgDOnmgM\r
+0fGFQs5J6SxSL6DrOnOfqlJrS9g5C44OU0vx+Qa2puX5kA2kSN03PA0VZBkTD7nr\r
+Wi6Bwl+4AHREtts8gU3YdBoQoiLAjVRznblIHJN8BlKiQAlTZUbOLDTPVGINdj/J\r
+Y+H01tLZkP/jn+XUFghjjFF41r8lLVcqXR/t6v/ySzEplUW5nfLDm540wBCV5jne\r
+HyoZCnFdXKTNDxcDls8ru+OzjKcRnf/FGLcPa9aqEaCaWNX+pK02uJwTcBdX9peW\r
+L8SHjWjbZ2+jWkxrywzt4DY9ZOPinbDKepj9ek6jzwgpq03TofoK2ZPfnOIuV5hn\r
++RJN/ngKbnT8uOR30EXk\r
+=C3PH\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r