thread merge/split proposal
authorDaniel Kahn Gillmor <dkg@fifthhorseman.net>
Mon, 4 Apr 2016 17:14:27 +0000 (14:14 +2100)
committerW. Trevor King <wking@tremily.us>
Sat, 20 Aug 2016 23:21:29 +0000 (16:21 -0700)
63/81e2b44b0289f08f1495ee218445a332615e5e [new file with mode: 0644]

diff --git a/63/81e2b44b0289f08f1495ee218445a332615e5e b/63/81e2b44b0289f08f1495ee218445a332615e5e
new file mode 100644 (file)
index 0000000..fbeb299
--- /dev/null
@@ -0,0 +1,116 @@
+Return-Path: <dkg@fifthhorseman.net>\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 671CA6DE0319\r
+ for <notmuch@notmuchmail.org>; Mon,  4 Apr 2016 10:14:46 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.037\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.037 tagged_above=-999 required=5\r
+ tests=[AWL=-0.037] 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 vFC9l1Ll-IPo for <notmuch@notmuchmail.org>;\r
+ Mon,  4 Apr 2016 10:14:38 -0700 (PDT)\r
+Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108])\r
+ by arlo.cworth.org (Postfix) with ESMTP id 5DBF86DE02C2\r
+ for <notmuch@notmuchmail.org>; Mon,  4 Apr 2016 10:14:38 -0700 (PDT)\r
+Received: from fifthhorseman.net (dhcp-a320.meeting.ietf.org [31.133.163.32])\r
+ by che.mayfirst.org (Postfix) with ESMTPSA id E05E8F991\r
+ for <notmuch@notmuchmail.org>; Mon,  4 Apr 2016 13:14:35 -0400 (EDT)\r
+Received: by fifthhorseman.net (Postfix, from userid 1000)\r
+ id E2C162018C; Mon,  4 Apr 2016 14:14:30 -0300 (BRT)\r
+From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>\r
+To: Notmuch Mail <notmuch@notmuchmail.org>\r
+Subject: thread merge/split proposal\r
+User-Agent: Notmuch/0.21+124~gbf604e9 (http://notmuchmail.org) Emacs/24.5.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Mon, 04 Apr 2016 14:14:27 -0300\r
+Message-ID: <87mvp9uwi4.fsf@alice.fifthhorseman.net>\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: Mon, 04 Apr 2016 17:14:46 -0000\r
+\r
+--=-=-=\r
+Content-Type: text/plain\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+Some people i communicate with regularly break threads when\r
+replying. This is a major pain.  I'd like to be able to tell notmuch\r
+(perhaps programmatically) how to connect these threads.\r
+\r
+I know we've talked about being able to join threads, but no one has\r
+made such a change in notmuch, afaict.  One of the major concerns people\r
+have about joining threads is that the action seems irreversible.\r
+\r
+If it were reversible (if it were easy to split a joined thread back\r
+into its original threads), maybe it would be less scary to have a "join\r
+thread" implementation?\r
+\r
+i see two ways to do this:\r
+\r
+ a) store an "original thread" attribute for each message that has been\r
+    joined, and just reset it when an unjoin is requested\r
+\r
+or\r
+\r
+ b) when an unjoin is requested, do a graph analysis of every message in\r
+    the thread's In-Reply-To and References headers, and recreate\r
+    distinct threads from the connected components.\r
+\r
+\r
+the problem with (a) is that once threads are joined, and a new message\r
+is added to the joined thread, it's not clear which it should have as\r
+its "original thread".\r
+\r
+So what do folks think about (b)?  If that was implemented, would it be\r
+less-scary to have a "join thread" operation?\r
+\r
+From=20the CLI, it would look something like:\r
+\r
+  notmuch join-threads THREAD_A THREAD_B [ THREAD_C ... ]\r
+  notmuch split-thread THREAD_X\r
+\r
+What do people think about this approach?\r
+\r
+     --dkg\r
+\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature; name="signature.asc"\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v2\r
+\r
+iQJ8BAEBCgBmBQJXAqDzXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w\r
+ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUy\r
+NEVDRkY1QUZGNjgzNzBBAAoJECTs/1r/aDcKLKMP/0E0Y2uc0fLdK7V0JNLusGaw\r
+JKeNBj6QOFu9FR4eFvnqc2zmJYOsO5ZQ2ZVwz5MilEDNv5ZUieFPWBDCIybVZp6d\r
+YzLK2o00OSC9GWgbaWSktlDTmEu99JywIrlC+qDeoZEp0e1Fz0IJUuhxEm2fyT+5\r
+vLwc/jMkbaxNTX4s6fF1xRr9nJ0boJtjULSaiKgX8IpS4M86vqygK9MbW+3DNWnk\r
+F5RdnQ6v8b376pmt6rWmgUSJPQZ55um6abCPbZkahmSzXrgKa6qmDE2v8L91Q2rD\r
+gp5MowUy36FfN6llwPc3qxnCcpDY9UFfXpdefloQ5mHYZpm51MU7ZDOyxiRatd6w\r
+rokQkD3K09bg4nl9vjEPwVhLCDMR7Wn5xLClJkLFhhAc8vS9/itYWDOK7nj6kXfY\r
+Zop1BPf0pn6563pQcVY38U5i8Ux3lJWSoE2GRmkqVdB1jAoOnH8oqViRKLA830eS\r
+++GHidue3xIjG8gNPWbWlwpkoTN+JV6UGZtFOyKDlTBuT43MshpEhFIR/sa1nojo\r
+zteu74X0g3pkLQqWJpYX/y5fyOgQSgQAc0ZV/D1p0NK3+YQ26jFKmUeyTjMktMFx\r
+Ue5yY+ejNdrlkQE1rMms451TS8swy2HfZzOyZvOMExH60TX/a4KlhWVE1rU5n8lY\r
+FBUinh7JY3CJ3+GYcY8i\r
+=3MYb\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r