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 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----- --=-=-=--