36/2294cfb3d7764013f3ee1b48383a0c804afb4e

   1 Return-Path: <amdragon@mit.edu>\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 294FE431E62\r
   6         for <notmuch@notmuchmail.org>; Wed, 15 Feb 2012 16:00:52 -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: -0.7\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
  12         tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id O5CgZm-e1k8w for <notmuch@notmuchmail.org>;\r
  16         Wed, 15 Feb 2012 16:00:51 -0800 (PST)\r
  17 Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU\r
  18         [18.7.68.36])\r
  19         by olra.theworths.org (Postfix) with ESMTP id 7230C429E42\r
  20         for <notmuch@notmuchmail.org>; Wed, 15 Feb 2012 16:00:51 -0800 (PST)\r
  21 X-AuditID: 12074424-b7fae6d000000906-32-4f3c4731432b\r
  22 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43])\r
  23         by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP\r
  24         id 97.6D.02310.1374C3F4; Wed, 15 Feb 2012 19:00:49 -0500 (EST)\r
  25 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])\r
  26         by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id q1G00mTT030779; \r
  27         Wed, 15 Feb 2012 19:00:49 -0500\r
  28 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91])\r
  29         (authenticated bits=0)\r
  30         (User authenticated as amdragon@ATHENA.MIT.EDU)\r
  31         by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q1G00kdu020719\r
  32         (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);\r
  33         Wed, 15 Feb 2012 19:00:47 -0500 (EST)\r
  34 Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.77)\r
  35         (envelope-from <amdragon@mit.edu>)\r
  36         id 1Rxokd-0008Ot-Kc; Wed, 15 Feb 2012 18:59:07 -0500\r
  37 Date: Wed, 15 Feb 2012 18:59:07 -0500\r
  38 From: Austin Clements <amdragon@MIT.EDU>\r
  39 To: Jameson Graef Rollins <jrollins@finestructure.net>\r
  40 Subject: Re: [RFC PATCH v5 00/11] Add NOTMUCH_MESSAGE_FLAG_EXCLUDED flag\r
  41 Message-ID: <20120215235907.GY27039@mit.edu>\r
  42 References: <1329296619-7463-1-git-send-email-markwalters1009@gmail.com>\r
  43         <8739acrnu7.fsf@servo.finestructure.net>\r
  44         <8739aber9o.fsf@qmul.ac.uk>\r
  45         <874nurrbdb.fsf@servo.finestructure.net>\r
  46 MIME-Version: 1.0\r
  47 Content-Type: text/plain; charset=us-ascii\r
  48 Content-Disposition: inline\r
  49 In-Reply-To: <874nurrbdb.fsf@servo.finestructure.net>\r
  50 User-Agent: Mutt/1.5.21 (2010-09-15)\r
  51 X-Brightmail-Tracker:\r
  52  H4sIAAAAAAAAA+NgFuphleLIzCtJLcpLzFFi42IR4hTV1jV0t/E3aJ4obrFnn5fF6rk8Ftdv\r
  53         zmR2YPa4e5rLY+esu+wez1bdYg5gjuKySUnNySxLLdK3S+DKmLlwAmPBY56KV6feszUwTuXq\r
  54         YuTkkBAwkTixbDoLhC0mceHeerYuRi4OIYF9jBJ/J01nhHA2MErM2faBCcI5ySSx6tAVKGcJ\r
  55         o8TJS48YQfpZBFQlFjT9ZgKx2QQ0JLbtXw4WFxEwk+j58gfMZhZwlZhxYRdYjbCAh8SShxPZ\r
  56         QWxeAR2JxqVzWSGG7mGU2LVqDlRCUOLkzCcsEM1aEjf+vQRq5gCypSWW/+MACXMKmEp83HwA\r
  57         bL6ogIrElJPb2CYwCs1C0j0LSfcshO4FjMyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdM31cjNL\r
  58         9FJTSjcxggKd3UVlB2PzIaVDjAIcjEo8vBzMNv5CrIllxZW5hxglOZiURHm/ugKF+JLyUyoz\r
  59         Eosz4otKc1KLDzFKcDArifBqT7f2F+JNSaysSi3Kh0lJc7AoifNqaL3zExJITyxJzU5NLUgt\r
  60         gsnKcHAoSfBudAMaKliUmp5akZaZU4KQZuLgBBnOAzR8IkgNb3FBYm5xZjpE/hSjopQ473KQ\r
  61         hABIIqM0D64XloheMYoDvSLMOwmkigeYxOC6XwENZgIabP7CCmRwSSJCSqqBUe5NiW0541q3\r
  62         TWsbIrt4zxdxuU/muRL7MX+SCWvonr0blPlfv5YOq3rFx14gnGDmLhpc+1R8qtv07fLLNRaf\r
  63         qUgrTrnF1/NJ0dbt6YG04AUH7+69s9q04i1DFZM7L3fyhz6fD7rFJZm/9+7xUZjIzeixdarg\r
  64         jvApAgHX/fOj9p5KcqjsNkhVYinOSDTUYi4qTgQAET4B7x8DAAA=\r
  65 Cc: notmuch@notmuchmail.org\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:00:52 -0000\r
  79 \r
  80 Quoth Jameson Graef Rollins on Feb 15 at  2:16 pm:\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 There's been a fair bit of discussion of this at\r
  88 id:"871uqvgrnm.fsf@qmul.ac.uk" (already pointed out on IRC, but I\r
  89 figured I'd point it out here for others).\r
  90 \r
  91 There are some drawbacks to separating out the exclude flag, but\r
  92 personally I think they're minor and that doing so opens up a lot of\r
  93 interesting UI possibilities as well as providing a very clean and\r
  94 consistent interface.\r
  95 \r
  96 > > 1) What should notmuch show id:deleted-message-id do? \r
  97 > > \r
  98 > > It could return the thread containing the deleted message. If it does\r
  99 > > return a thread what subject does it assign it?  Possibly it could\r
 100 > > return no messages and the caller would have to call it again with\r
 101 > > --no-exclude.\r
 102 > \r
 103 > "notmuch show id:<excluded-id>" should always return the message\r
 104 > matching id:<excluded-id> with match=true.  In fact, any search that\r
 105 > references a specific id: should always process the message as if there\r
 106 > were no excludes at all.\r
 107 \r
 108 This sounds terribly inconsistent to me.  Even setting that aside, I\r
 109 can't think of a reasonable way to implement this.  What does it mean\r
 110 for a search to reference a specific id?  Do you special case when the\r
 111 query begins with the string "id:"?  Do you parse the query?  Do you\r
 112 check if the unexcluded search matches exactly one message and do\r
 113 something different in that case?\r