--- /dev/null
+Return-Path: <cworth@cworth.org>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by arlo.cworth.org (Postfix) with ESMTP id B406D6DE02C4\r
+ for <notmuch@notmuchmail.org>; Thu, 4 Aug 2016 12:44:15 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -9\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-9 tagged_above=-999 required=5 tests=[AM.WBL=-8,\r
+ ALL_TRUSTED=-1] autolearn=disabled\r
+Received: from arlo.cworth.org ([127.0.0.1])\r
+ by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id sPXbw_6pqzlq; Thu, 4 Aug 2016 12:44:08 -0700 (PDT)\r
+Received: from wondoo.home.cworth.org (unknown [10.0.0.1])\r
+ (Authenticated sender: cworth)\r
+ by arlo.cworth.org (Postfix) with ESMTPSA id 0B6216DE02AF;\r
+ Thu, 4 Aug 2016 12:44:08 -0700 (PDT)\r
+Received: from wondoo.home.cworth.org (localhost [IPv6:::1])\r
+ by wondoo.home.cworth.org (Postfix) with ESMTPS id E5A8914C41A5;\r
+ Thu, 4 Aug 2016 12:44:07 -0700 (PDT)\r
+To: Matt Armstrong <marmstrong@google.com>, Jani Nikula <jani@nikula.org>,\r
+ notmuch@notmuchmail.org\r
+Subject: Re: notmuch.el: controlling what does and doesn't get expanded in\r
+ searches\r
+In-Reply-To: <qf57fbw4fx4.fsf@marmstrong-linux.kir.corp.google.com>\r
+References: <qf54m70o7h5.fsf@marmstrong-linux.kir.corp.google.com>\r
+ <87a8gsv787.fsf@nikula.org>\r
+ <qf57fbw4fx4.fsf@marmstrong-linux.kir.corp.google.com>\r
+User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.5.1\r
+ (x86_64-pc-linux-gnu)\r
+Sender: cworth@cworth.org\r
+From: Carl Worth <cworth@cworth.org>\r
+Date: Thu, 04 Aug 2016 12:44:07 -0700\r
+Message-ID: <87r3a4nwu0.fsf@wondoo.home.cworth.org>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+ micalg=pgp-sha512; protocol="application/pgp-signature"\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.20\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <https://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: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Thu, 04 Aug 2016 19:44:15 -0000\r
+\r
+--=-=-=\r
+Content-Type: text/plain\r
+\r
+On Thu, Aug 04 2016, Matt Armstrong wrote:\r
+> Yes, I find the query semantics with respect to tags and threads a bit\r
+> confusing at times. This is not a problem specific to notmuch, as I\r
+> find the same kinds of issues in GMail. Usually the problem occurs at\r
+> the semantic border between per-message tags and thread-based\r
+> operations.\r
+>\r
+> I can now explain what I am seeing.\r
+\r
+Hi Matt,\r
+\r
+I haven't been very active on the notmuch mailing list in quite some\r
+time, but I wanted to poke my head in quickly to welcome you and to\r
+thank you for your contribution.\r
+\r
+I really like detailed discussions like this about coming up with good\r
+workflows, and trying to figure out how notmuch could better accommodate\r
+those workflows. I think this is one of the most valuable aspects of\r
+notmuch, (that it lets us ask these kinds of questions).\r
+\r
+So, please, keep it up!\r
+\r
+> i) notmuch could have an "also expand tags" feature, where thread based\r
+> results would auto expand matching tags. I would set this to\r
+> "unread".\r
+\r
+This approach makes a lot of sense to me based on how notmuch.el works.\r
+\r
+> ii) notmuch could have an "expand query" feature, where thread based\r
+> results would use an entirely different query to decide, within a\r
+> thread, which messages to expand. I would set this query to\r
+> "tag:unread".\r
+\r
+This approach would necessarily be quite a bit more complex in the\r
+implementation without much difference in the user-visible behavior. So\r
+I don't think we would want to pursue this.\r
+\r
+-Carl\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature; name="signature.asc"\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1\r
+\r
+iQIcBAEBCgAGBQJXo5sHAAoJEGACM7qeVNxhB98P/iQ0KuhvyEuTZ6xh4njYltyn\r
+xoUqoWtFWpDmb+DQjQYOFJ/HG3DNFu1pV7uAs9tnz1EqoGh2XuAGEiKse53+SsXW\r
+YIuOzjxpaIoOcg0osAKFqffyADAdZarJJ2xgaNJTr2TvBt0JI6X1TWnrdeBX5RvA\r
+46dqxVpQFv4ER7yUzLXE6q/bwZ9LyP+zG7w+P87Z3hKa19eazHYv3Fcb+4xwHln8\r
+XRiwdJ/xRXVx0RfvEwjcPtoiKRRsv24ldV+s0H4ZJ4gaWFbpXI/z7lPE3AFwAjtA\r
+At2M3t+l12EpPvciC3DqzV2bIdfwJBJ9RWt4YsAPOx37LE8CYj8pp+rIxSQjCmLZ\r
+SdZqCtyO5nSA/FIDGTf2UEvyiMWVitHDR8/DBDpM3Ld83llsAoaVnL6EYJAHBpGP\r
+LRoJOYiF3UBAZ2ZEiAnN3i192Za/r5vJXJ0TCz9SS2q+4SVYWyK+OvnKWduU9kWK\r
+0s11vL4qm4rvS/hdnsiC+Yy8Os6cUTehpSfhH/Fsg8Yevysb0JEP9rZP0s4mKtlt\r
+3kw9XA1ZIrY2UuBuJrHcgmGEGuK9BcxAVPKA7ZLnhdr3crbrmQnylDXm3bqjLOJt\r
+uimxAhGi2cNuMhoU/+Vlx4dAe7SUZNcqehDKRYTCJ98OY69EDJGi+1Tk02a/ja1U\r
+u4Ou8NZLPh+uBU+HNP/E\r
+=enVG\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r