From 6ab1e69f883f5a13c5998eb260d7864eece7fd4f Mon Sep 17 00:00:00 2001 From: Jameson Graef Rollins Date: Thu, 16 Feb 2012 14:16:16 +1600 Subject: [PATCH] Re: [RFC PATCH v5 00/11] Add NOTMUCH_MESSAGE_FLAG_EXCLUDED flag --- 54/30a46db702c138972091da21053820690d528c | 132 ++++++++++++++++++++++ 1 file changed, 132 insertions(+) create mode 100644 54/30a46db702c138972091da21053820690d528c diff --git a/54/30a46db702c138972091da21053820690d528c b/54/30a46db702c138972091da21053820690d528c new file mode 100644 index 000000000..7b1667f0d --- /dev/null +++ b/54/30a46db702c138972091da21053820690d528c @@ -0,0 +1,132 @@ +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 1A7E6431E82 + for ; Wed, 15 Feb 2012 14:16:25 -0800 (PST) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: -2.29 +X-Spam-Level: +X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 + tests=[RCVD_IN_DNSWL_MED=-2.3, T_MIME_NO_TEXT=0.01] 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 Nxdm0KQLPXyc for ; + Wed, 15 Feb 2012 14:16:23 -0800 (PST) +Received: from outgoing-mail.its.caltech.edu (outgoing-mail.its.caltech.edu + [131.215.239.19]) + by olra.theworths.org (Postfix) with ESMTP id EB2A8431E62 + for ; Wed, 15 Feb 2012 14:16:22 -0800 (PST) +Received: from fire-doxen.imss.caltech.edu (localhost [127.0.0.1]) + by fire-doxen-postvirus (Postfix) with ESMTP id 29EBB328064; + Wed, 15 Feb 2012 14:16:22 -0800 (PST) +X-Spam-Scanned: at Caltech-IMSS on fire-doxen by amavisd-new +Received: from finestructure.net (DHCP-123-180.caltech.edu [131.215.123.180]) + (Authenticated sender: jrollins) + by fire-doxen-submit (Postfix) with ESMTP id 5100F2E50D9A; + Wed, 15 Feb 2012 14:16:19 -0800 (PST) +Received: by finestructure.net (Postfix, from userid 1000) + id F20A84D3; Wed, 15 Feb 2012 14:16:18 -0800 (PST) +From: Jameson Graef Rollins +To: Mark Walters , notmuch@notmuchmail.org +Subject: Re: [RFC PATCH v5 00/11] Add NOTMUCH_MESSAGE_FLAG_EXCLUDED flag +In-Reply-To: <8739aber9o.fsf@qmul.ac.uk> +References: <1329296619-7463-1-git-send-email-markwalters1009@gmail.com> + <8739acrnu7.fsf@servo.finestructure.net> + <8739aber9o.fsf@qmul.ac.uk> +User-Agent: Notmuch/0.11.1+192~g2bb5859 (http://notmuchmail.org) Emacs/23.3.1 + (x86_64-pc-linux-gnu) +Date: Wed, 15 Feb 2012 14:16:16 -0800 +Message-ID: <874nurrbdb.fsf@servo.finestructure.net> +MIME-Version: 1.0 +Content-Type: multipart/signed; boundary="=-=-="; + micalg=pgp-sha256; protocol="application/pgp-signature" +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: Wed, 15 Feb 2012 22:16:25 -0000 + +--=-=-= +Content-Transfer-Encoding: quoted-printable + +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?=20 +>=20 +> 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=3Dtrue. 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?=20 +>=20 +> 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: + +=2D excluded messages are just match=3Dfalse + +=2D searches that reference a specific id: are match=3Dtrue no matter what + their exclude status + +=2D searches that reference an excluded tag are match=3Dtrue + +As far as I can see this should "just work", without any existing +changes to consumers. Anyone see any issues I'm missing? + +jamie. + +--=-=-= +Content-Type: application/pgp-signature + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.4.11 (GNU/Linux) + +iQIcBAEBCAAGBQJPPC6wAAoJEO00zqvie6q82KAP/iS+8YA2Rg12NNcjQvFLgRMi +Uv6Fhd8tcbaRNASitOigUXVutWdzZMxiteOAOxo+4king614l+7dek/Cv0aChozT +bZtkhKmIv4jZPuyWm2kOpmULxJY+ehsQ74jmq7UOoxEyZtytEbLI7HSWPCe9LFAX +vdq5SC1fTNopxfdxpF9D5XCiIm6/T5gdT/moCa+BuhvFu/qOJ6UA4AZ7CiM9YbBV +ndr/fW203wY6CpUdHnI9XXvcQTF03FKrFKkvaSWlHOxlwO+wOxsWf4glEVPMn/4L +w9hlu+4qM7LbB7Iolxc0B6UNo8mHZz/XDerC7kaHOSO3H6+xVH40QCR0kgDOnmgM +0fGFQs5J6SxSL6DrOnOfqlJrS9g5C44OU0vx+Qa2puX5kA2kSN03PA0VZBkTD7nr +Wi6Bwl+4AHREtts8gU3YdBoQoiLAjVRznblIHJN8BlKiQAlTZUbOLDTPVGINdj/J +Y+H01tLZkP/jn+XUFghjjFF41r8lLVcqXR/t6v/ySzEplUW5nfLDm540wBCV5jne +HyoZCnFdXKTNDxcDls8ru+OzjKcRnf/FGLcPa9aqEaCaWNX+pK02uJwTcBdX9peW +L8SHjWjbZ2+jWkxrywzt4DY9ZOPinbDKepj9ek6jzwgpq03TofoK2ZPfnOIuV5hn ++RJN/ngKbnT8uOR30EXk +=C3PH +-----END PGP SIGNATURE----- +--=-=-=-- -- 2.26.2