0e/34a4da85c07557b53dce71c97c18f76674d0f5

   1 Return-Path: <marmstrong@google.com>\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 arlo.cworth.org (Postfix) with ESMTP id 79AA96DE0356\r
   6  for <notmuch@notmuchmail.org>; Thu,  4 Aug 2016 10:12:21 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at cworth.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.819\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.819 tagged_above=-999 required=5 tests=[AWL=0.012,\r
  12   DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
  13  RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01,\r
  14  SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=disabled\r
  15 Received: from arlo.cworth.org ([127.0.0.1])\r
  16  by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
  17  with ESMTP id SogO1YgbpPcu for <notmuch@notmuchmail.org>;\r
  18  Thu,  4 Aug 2016 10:12:13 -0700 (PDT)\r
  19 Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com\r
  20  [209.85.220.54])\r
  21  by arlo.cworth.org (Postfix) with ESMTPS id 3B0016DE02B5\r
  22  for <notmuch@notmuchmail.org>; Thu,  4 Aug 2016 10:12:13 -0700 (PDT)\r
  23 Received: by mail-pa0-f54.google.com with SMTP id iw10so84388112pac.2\r
  24  for <notmuch@notmuchmail.org>; Thu, 04 Aug 2016 10:12:13 -0700 (PDT)\r
  25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\r
  26  s=20120113;\r
  27  h=from:to:subject:in-reply-to:references:user-agent:date:message-id\r
  28  :mime-version; bh=+VMXkONMBoQw++SK5PR6GyUCtfE620smFTCaOcz6RHw=;\r
  29  b=HPfDXr+OS7g3FXntfrki1qd8ii1oYZHsMunOjkwZaZL4h3hFQ3Az3/KUJJDpBGzgks\r
  30  l5HNi6MX+5N6QVlXQ/ALKdtCgriZcESCfG4KipJzULMRCn/AwN41RnSISqqzPDLM6d6W\r
  31  ZIxUrpEoKcExdE7ZTVn7ViGOqy/qT3iqSQ7kijw/lAKinRQyhx4MCpQGFGUuET5T/q+N\r
  32  81YRyRQOxytTBc0MzUFkEPkIsbiDWXuNR2rntHUPMWR1DIUoRnrqix3eVk/yyW2POJZ6\r
  33  pHYsBNmo1ghXTf/MD0KyeqsIXMttYHlAcErsZe1TKaVfoQqnYz9WJuug2A5JSRVwqbLW LQAg==\r
  34 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
  35  d=1e100.net; s=20130820;\r
  36  h=x-gm-message-state:from:to:subject:in-reply-to:references\r
  37  :user-agent:date:message-id:mime-version;\r
  38  bh=+VMXkONMBoQw++SK5PR6GyUCtfE620smFTCaOcz6RHw=;\r
  39  b=Cgn8qcXlUroG2+6b6uhnhbWC3IDLDxC3qvclFYjAzwz1uwOtxJCPYJocVQw2uNozo2\r
  40  NUupLSP+RdCR5m1uvD9GH0cieyn56L6x0ZfQslR1hZe0foPZmkFSoUEDlWYk32NsVRos\r
  41  +aFP9ggJYPXwpVaeu1332vsOmDd3UZMocbQVR0RtIt38MWqoIbw+HNfDEzna/L6920x2\r
  42  AJ7tt2gFyAWl2fhw7ODL6/wa5XP0QIBOKX2toaZYFno7jyFrGaMZvRYA2wuVv5/wfW1N\r
  43  ALJzsd2lwueDC+pdTXlsWN+HvloBU3ulDezsK8LMNx+HkR7qtz+B/V4+srTp18QYAD7B\r
  44  6MRw==\r
  45 X-Gm-Message-State:\r
  46  AEkoouurubDgfCTcrB0Q7RgBWxUtRezZm8IQchuR3odhbXkOeLZYcauxrAvmnwXhQAeNsFnk\r
  47 X-Received: by 10.66.62.226 with SMTP id b2mr127671998pas.119.1470330732305;\r
  48  Thu, 04 Aug 2016 10:12:12 -0700 (PDT)\r
  49 Received: from marmstrong-linux.kir.corp.google.com\r
  50  ([2620:0:1008:11:9d01:ef49:41c8:1902])\r
  51  by smtp.gmail.com with ESMTPSA id sy7sm4708834pac.42.2016.08.04.10.12.09\r
  52  (version=TLS1_2 cipher=AES128-SHA bits=128/128);\r
  53  Thu, 04 Aug 2016 10:12:09 -0700 (PDT)\r
  54 From: Matt Armstrong <marmstrong@google.com>\r
  55 To: Jani Nikula <jani@nikula.org>, notmuch@notmuchmail.org\r
  56 Subject: Re: notmuch.el: controlling what does and doesn't get expanded in\r
  57  searches\r
  58 In-Reply-To: <87a8gsv787.fsf@nikula.org>\r
  59 References: <qf54m70o7h5.fsf@marmstrong-linux.kir.corp.google.com>\r
  60  <87a8gsv787.fsf@nikula.org>\r
  61 User-Agent: Notmuch/0.22.1+62~g2a7b11b (https://notmuchmail.org) Emacs/24.3.1\r
  62  (x86_64-pc-linux-gnu)\r
  63 Date: Thu, 04 Aug 2016 10:12:07 -0700\r
  64 Message-ID: <qf57fbw4fx4.fsf@marmstrong-linux.kir.corp.google.com>\r
  65 MIME-Version: 1.0\r
  66 Content-Type: text/plain\r
  67 X-BeenThere: notmuch@notmuchmail.org\r
  68 X-Mailman-Version: 2.1.20\r
  69 Precedence: list\r
  70 List-Id: "Use and development of the notmuch mail system."\r
  71  <notmuch.notmuchmail.org>\r
  72 List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,\r
  73  <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  74 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
  75 List-Post: <mailto:notmuch@notmuchmail.org>\r
  76 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  77 List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
  78  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  79 X-List-Received-Date: Thu, 04 Aug 2016 17:12:21 -0000\r
  80 \r
  81 Jani Nikula <jani@nikula.org> writes:\r
  82 \r
  83 > On Thu, 04 Aug 2016, Matt Armstrong <marmstrong@google.com> wrote:\r
  84 >> This question pertains to notmuch built from recent git HEAD, using\r
  85 >> notmuch.el in show mode (i.e. not tree mode).\r
  86 >>\r
  87 >> I sometimes read a thread with a bunch of messages and notmuch.el\r
  88 >> collapses a bunch of them (even if unread and the search matches tags\r
  89 >> in every message).  I can't figure out the heuristic notmuch is\r
  90 >> applying here.\r
  91 >\r
  92 > The idea is that all the messages matching the query are expanded, the\r
  93 > others collapsed. Each expanded message must fully match the query. The\r
  94 > unread or inbox tags are not special in this regard.\r
  95 >\r
  96 > I am not saying this is ideal, but this is how it's supposed to\r
  97 > work. (Indeed I'd personally like to define e.g. saved search specific\r
  98 > tags or queries to use for deciding which messages to expand.)\r
  99 \r
 100 Thank you.\r
 101 \r
 102 Yes, I find the query semantics with respect to tags and threads a bit\r
 103 confusing at times.  This is not a problem specific to notmuch, as I\r
 104 find the same kinds of issues in GMail.  Usually the problem occurs at\r
 105 the semantic border between per-message tags and thread-based\r
 106 operations.\r
 107 \r
 108 I can now explain what I am seeing.  In my notmuch-post-hook I tag\r
 109 messages according to various categories (mailing lists, etc.).  Every\r
 110 time I do this I also tag them with 'filtered'.  My\r
 111 `notmuch-saved-searches` has about 15 sub-queries of the form "tag:inbox\r
 112 AND tag:<something>".\r
 113 \r
 114 I also have a saved search to catch the "unfiltered" stuff:\r
 115 \r
 116   tag:inbox AND tag:unfiltered\r
 117 \r
 118 So this occurred:\r
 119 \r
 120 1) One message was sent to a foo-announce mailing list.  This was not\r
 121    caught by my filters, so it was simply tagged 'inbox'.\r
 122 \r
 123 2) All replies were sent to the main "foo" mailing list, which *was*\r
 124    caught by my filters and tagged 'inbox' and 'foo' and 'filtered'.\r
 125 \r
 126 This is bad for two reasons:\r
 127 \r
 128 a) If I observed this thread by searching for 'tag:inbox AND tag:foo',\r
 129    the initial foo-announce message would not be expanded.  But, as the\r
 130    first message in the thread, it is the most important!\r
 131 \r
 132 b) If I observed this thread by searching for 'tag:inbox AND not\r
 133    tag:filtered' (as I do to find all the "uncategorized" stuff in my\r
 134    inbox), then the foo-announce mail is expanded but none of the\r
 135    others.\r
 136 \r
 137 This problem isn't specific to my 'filtered' tag approach.  I think it\r
 138 generalizes to any approach that attempts to split incoming mail.\r
 139 \r
 140 I've been seeing this problem quite frequently because I'm in an\r
 141 environment where messages are cc:'d to different mailing lists all the\r
 142 time.  It is common for threads to be cc'd to new mailing lists\r
 143 mid-thread, or for people to pull lists off the cc: list mid-thread\r
 144 (sometimes into private per-person distribution).\r
 145 \r
 146 In this environment, different messages in those threads area expanded\r
 147 depending on which query I use to find them.  This is undesirable\r
 148 because, generally, I want to read every message I have not yet read in\r
 149 these threads.\r
 150 \r
 151 \r
 152 >> In particular, pressing SPC does not seem to navigate to the collapsed\r
 153 >> messages (again, even if they are unread).\r
 154 >\r
 155 > SPC and n and p are supposed to navigate expanded messages only. N and P\r
 156 > navigate all messages (but do not expand by default). Again, the tags\r
 157 > the messages have do not matter. You can manually expand/collapse\r
 158 > messages, and that'll affect the navigation.\r
 159 \r
 160 Note that SPC also archives, and when it does, it archives the entire\r
 161 thread, not just the expanded messages (i.e. those that match the\r
 162 current search).  So, this gave rise to the above situation, where I\r
 163 pressed SPC twice and archived a 40 message thread, with most messages\r
 164 still unread.\r
 165 \r
 166 \r
 167 >> Worst case: only the first messages is initially expanded and all\r
 168 >> subsequent are collapsed.  I press SPC and the cursor goes to the end\r
 169 >> of search results.  SPC again all the entire thread is archived.\r
 170 >>\r
 171 >> This behavior has caused me to accidentally skip messages.  First\r
 172 >> step for me is understanding what is going on so I can fix it.\r
 173 >\r
 174 > Yes, let's first check that notmuch behaves as it is expected, and\r
 175 > then figure out how to improve it.\r
 176 \r
 177 I think the semantics make coherent sense for ad-hoc searches.  Things\r
 178 break down for me when considering an inbox processing workflow heavily\r
 179 based on archiving.\r
 180 \r
 181 If I return to a thread after reading the first N messages I need not\r
 182 see those messages expanded.  I have already read them, so I'd prefer\r
 183 they be collapsed.  Not much usually does this for me because I archive\r
 184 aggressively, but I don't always archive.  In these cases I think I'd\r
 185 prefer expansion instead be based on whether I've read the message\r
 186 (tag:unread).\r
 187 \r
 188 Also, I do want threads consisting entirely of read messages to appear\r
 189 in my inbox searches, so I do not want to simply add "AND tag:unread" to\r
 190 all of my `notmuch-saved-searches`.\r
 191 \r
 192 Additionally, if messages that don't match the query are pulled into\r
 193 threads that don't match the query, and are "unread", I'd like to see\r
 194 them.  Such messages are quite likely to provide important context.\r
 195 \r
 196 I can think of two ideas:\r
 197 \r
 198  i) notmuch could have an "also expand tags" feature, where thread based\r
 199     results would auto expand matching tags.  I would set this to\r
 200     "unread".\r
 201 \r
 202  ii) notmuch could have an "expand query" feature, where thread based\r
 203      results would use an entirely different query to decide, within a\r
 204      thread, which messages to expand.  I would set this query to\r
 205      "tag:unread".\r
 206 \r
 207 This would be most natural with the current archive semantics in\r
 208 notmuch.el, which apply tags to entire threads on the assumption that\r
 209 SPC advances over them in meaningful ways.\r