Re: thread merge/split proposal

diff --git a/8d/820f5b190e867afbadedb3c3528042f2831046 b/8d/820f5b190e867afbadedb3c3528042f2831046
new file mode 100644 (file)
index 0000000..b6ec101
--- /dev/null
+++ b/8d/820f5b190e867afbadedb3c3528042f2831046
@@ -0,0 +1,95 @@
+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 609E16DE0319\r
+ for <notmuch@notmuchmail.org>; Mon,  4 Apr 2016 11:24:02 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.032\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.032 tagged_above=-999 required=5\r
+ tests=[AWL=-0.032] 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 u35Dz1b8793D for <notmuch@notmuchmail.org>;\r
+ Mon,  4 Apr 2016 11:23:54 -0700 (PDT)\r
+Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108])\r
+ by arlo.cworth.org (Postfix) with ESMTP id D98ED6DE0243\r
+ for <notmuch@notmuchmail.org>; Mon,  4 Apr 2016 11:23:53 -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 3A937F991\r
+ for <notmuch@notmuchmail.org>; Mon,  4 Apr 2016 14:23:50 -0400 (EDT)\r
+Received: by fifthhorseman.net (Postfix, from userid 1000)\r
+ id AA0FB2018C; Mon,  4 Apr 2016 15:23:43 -0300 (BRT)\r
+From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>\r
+To: Notmuch Mail <notmuch@notmuchmail.org>\r
+Subject: Re: thread merge/split proposal\r
+In-Reply-To: <87mvp9uwi4.fsf@alice.fifthhorseman.net>\r
+References: <87mvp9uwi4.fsf@alice.fifthhorseman.net>\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 15:23:43 -0300\r
+Message-ID: <87k2kdutao.fsf@alice.fifthhorseman.net>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\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 18:24:02 -0000\r
+\r
+On Mon 2016-04-04 14:14:27 -0300, Daniel Kahn Gillmor wrote:\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
+>  From the 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
+On IRC, bremner pointed out two specific improvements to this proposal:\r
+\r
+ 0) the inverse operation of "join" proposed above is distinct from the\r
+    ongoing discussion about splitting threads in arbitrary places.  I\r
+    don't want to conflate these issues, so my proposed\r
+    connected-component-analysis operation should be "notmuch\r
+    unjoin-thread", and not "notmuch split-thread"\r
+\r
+ 1) a "join" operation probably has to be stored explicitly in the\r
+    database, so that the threads will be re-joined across a\r
+    dump/restore operation.\r
+\r
+I'm happy with both of these improvements.\r
+\r
+for (1) i'd propose that the join operation would be implemented by\r
+adding a new term type "join", which can be applied to any document.\r
+Its value is the message-id of a message that *should* be "in-reply-to"\r
+but wasn't.\r
+\r
+So for example: messages A and B are in one thread; messages C and D\r
+come in in a separate thread that should have been joined to the prior\r
+thread but is not.\r
+\r
+i propose implementing this as something like:\r
+\r
+    notmuch_message_add_term(message_c, "join", get_message_id(message_a));\r
+  \r
+    notmuch_message_set_thread_id(message_c, get_thread_id(message_a));\r
+    notmuch_message_set_thread_id(message_d, get_thread_id(message_a));\r
+\r
+i'd also add all the "join" terms to "notmuch dump", though i'm not sure\r
+exactly how to extend the "notmuch dump" format.\r
+\r
+feedback welcome,\r
+\r
+        --dkg\r