RE: Reply all - issue

diff --git a/cd/0aba0966eabe604018956a9f1b8db8848226fe b/cd/0aba0966eabe604018956a9f1b8db8848226fe
new file mode 100644 (file)
index 0000000..3dafa6f
--- /dev/null
+++ b/cd/0aba0966eabe604018956a9f1b8db8848226fe
@@ -0,0 +1,111 @@
+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 olra.theworths.org (Postfix) with ESMTP id 93B6A431FB6\r
+       for <notmuch@notmuchmail.org>; Tue, 12 Feb 2013 11:14:32 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
+       autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id 6yAEgKhSGjB5 for <notmuch@notmuchmail.org>;\r
+       Tue, 12 Feb 2013 11:14:32 -0800 (PST)\r
+Received: from arlo.cworth.org (arlo.cworth.org [50.126.95.6])\r
+       (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id 09EA2431FAF\r
+       for <notmuch@notmuchmail.org>; Tue, 12 Feb 2013 11:14:32 -0800 (PST)\r
+Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
+       by arlo.cworth.org (Postfix) with ESMTP id 0D0BE6DE0941;\r
+       Tue, 12 Feb 2013 11:14:30 -0800 (PST)\r
+Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
+       id 44C3E64933; Wed, 13 Feb 2013 06:17:18 +1100 (EST)\r
+From: Carl Worth <cworth@cworth.org>\r
+To: Jameson Graef Rollins <jrollins@finestructure.net>,\r
+       David Bremner <david@tethera.net>,\r
+       Robert Mast <beheerder@tekenbeetziekten.nl>,\r
+       'Jani Nikula' <jani@nikula.org>, notmuch@notmuchmail.org\r
+Subject: RE: Reply all - issue\r
+In-Reply-To: <87sj52nh6h.fsf@servo.finestructure.net>\r
+References: <000001cdfcd9$82500f00$86f02d00$@nl> <87wquxjq7k.fsf@nikula.org>\r
+       <002601cdfd83$83b283f0$8b178bd0$@nl>\r
+       <87boc8bt8a.fsf@yoom.home.cworth.org>\r
+       <000001cdff33$afe11070$0fa33150$@nl>\r
+       <87txpykve8.fsf@zancas.localnet> <87r4l2kvak.fsf@zancas.localnet>\r
+       <87sj52nh6h.fsf@servo.finestructure.net>\r
+User-Agent: Notmuch/0.13.1 (http://notmuchmail.org) Emacs/23.4.1\r
+       (x86_64-pc-linux-gnu)\r
+Date: Tue, 12 Feb 2013 11:17:08 -0800\r
+Message-ID: <877gmdjqa3.fsf@yoom.home.cworth.org>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+       micalg=pgp-sha1; protocol="application/pgp-signature"\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://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: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Tue, 12 Feb 2013 19:14:32 -0000\r
+\r
+--=-=-=\r
+Content-Type: text/plain; charset=utf-8\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+Jameson Graef Rollins <jrollins@finestructure.net> writes:\r
+> Just a thought: what if messages with a given tag (e.g. "new-thread")\r
+> were always treated as the source of a new thread?\r
+\r
+It's a good start. And an approach like that would have the advantage\r
+that one could undo a thread-split by just removing the tag. (That's not\r
+an explicit thread-join feature, but I don't think anyone has ever asked\r
+for that.)\r
+\r
+> A message with the given tag could just be (re)indexed with any\r
+> In-Reply-To/References headers stripped before indexing.\r
+\r
+It would require a little more than that. Imagine this thread:\r
+\r
+  A: Subject: An original thread\r
+  =E2=94=94=E2=94=80B: Subject: Thread hijacking is fun (tag:new-thread)\r
+    =E2=94=94=E2=94=80C: Subject: Re: Thread hijacking is fun\r
+\r
+In this case, message C is likely to have a References header that\r
+mentions both A and B. So the thread stitching logic in notmuch will\r
+want to merge threads A and B when indexing C. So special care will have\r
+to be taken here as well, (not just when indexing B).\r
+\r
+And that special care may not be cheap if it requires additional\r
+database lookups for each unique thread ID encountered among references\r
+of a message.\r
+\r
+Though, I don't mean to dissuade anyone from thinking this through and\r
+coding it up. The relevant code for the pieces I'm referring to starts\r
+in _notmuch_database_link_message in lib/database.cc.\r
+\r
+=2DCarl\r
+\r
+=2D-=20\r
+carl.d.worth@intel.com\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.12 (GNU/Linux)\r
+\r
+iEYEARECAAYFAlEalTQACgkQ6JDdNq8qSWguyQCfbtLt8QIx19Mjhbb7q/5BuEJe\r
+z5sAniG0T+bewnGDgmcAd+IUAQOJpD7Z\r
+=su3/\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r