ae/33032c69d462b731401a75234e8dc7ad5968e8

   1 Return-Path: <cworth@cworth.org>\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 olra.theworths.org (Postfix) with ESMTP id 6ED0840DDE8\r
   6         for <notmuch@notmuchmail.org>; Fri, 12 Nov 2010 17:11:59 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -2.89\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5\r
  12         tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, T_MIME_NO_TEXT=0.01]\r
  13         autolearn=ham\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id Ku4ar9RbK-PZ; Fri, 12 Nov 2010 17:11:47 -0800 (PST)\r
  17 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  18         by olra.theworths.org (Postfix) with ESMTP id 2A46F40DDCB;\r
  19         Fri, 12 Nov 2010 17:11:47 -0800 (PST)\r
  20 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  21         id C8E9B25412B; Fri, 12 Nov 2010 17:11:46 -0800 (PST)\r
  22 From: Carl Worth <cworth@cworth.org>\r
  23 To: Scott Henson <scott@foolishpride.org>, notmuch <notmuch@notmuchmail.org>\r
  24 Subject: Re: Combining threads\r
  25 In-Reply-To: <AANLkTimDjk_-Xjpf6uovGXgyG_3j-ySLWQR+0UvdVjjT@mail.gmail.com>\r
  26 References: <AANLkTimDjk_-Xjpf6uovGXgyG_3j-ySLWQR+0UvdVjjT@mail.gmail.com>\r
  27 User-Agent: Notmuch/0.4 (http://notmuchmail.org) Emacs/23.2.1\r
  28         (i486-pc-linux-gnu)\r
  29 Date: Fri, 12 Nov 2010 17:11:46 -0800\r
  30 Message-ID: <87mxpe81t9.fsf@yoom.home.cworth.org>\r
  31 MIME-Version: 1.0\r
  32 Content-Type: multipart/signed; boundary="=-=-=";\r
  33         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  34 X-BeenThere: notmuch@notmuchmail.org\r
  35 X-Mailman-Version: 2.1.13\r
  36 Precedence: list\r
  37 List-Id: "Use and development of the notmuch mail system."\r
  38         <notmuch.notmuchmail.org>\r
  39 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  40         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  41 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  42 List-Post: <mailto:notmuch@notmuchmail.org>\r
  43 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  44 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  45         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  46 X-List-Received-Date: Sat, 13 Nov 2010 01:11:59 -0000\r
  47 \r
  48 --=-=-=\r
  49 \r
  50 On Fri, 12 Nov 2010 08:57:21 -0800, Scott Henson <scott@foolishpride.org> wrote:\r
  51 > Sometimes I get email from people with broken email clients that seem to\r
  52 > break threading.  I remember that sup had a method of combining two threads\r
  53 > into one.  Does notmuch have a similar feature?  Is it even possible to\r
  54 > force it to glue two threads together and treat them as one?\r
  55 \r
  56 There's no support for this in the command-line interface, nor even the\r
  57 library interface. But internally in the implementation there is a\r
  58 function that joins two threads together. It looks like this:\r
  59 \r
  60         static notmuch_status_t\r
  61         _merge_threads (notmuch_database_t *notmuch,\r
  62                         const char *winner_thread_id,\r
  63                         const char *loser_thread_id);\r
  64 \r
  65 This function is used regularly---for example, when two child messages\r
  66 arrive separately and each get their own thread[*], then later the parent\r
  67 arrives. At that point the two threads are merged with the above\r
  68 function.\r
  69 \r
  70 Now, if we did have good support for thread joining I could join your\r
  71 request with the reply I gave the last time the question came up. ;-)\r
  72 \r
  73 That was in this email:\r
  74 \r
  75         id:87vd4k6956.fsf@yoom.home.cworth.org\r
  76 \r
  77 And since we don't yet have a good web-based archive that lets you just\r
  78 plug in message IDs, I'll quote my reply here:\r
  79 \r
  80 > On Sat, 08 May 2010 14:36:26 +0200, Arvid Picciani <aep@exys.org> wrote:\r
  81 > > Most of my mail comes from the 50MLs i'm subscribed to. Unfortunately\r
  82 > > some MUAs suck that much, they don't even respond in threads.\r
  83 > > My idea how to fix them would be:\r
  84 >\r
  85 > People have previously asked for a feature to combine messages into the\r
  86 > same thread.\r
  87 >\r
  88 > And it would actually be a fairly simple operation. Perhaps it could be\r
  89 > something like:\r
  90 >\r
  91 > notmuch set-thread $(notmuch search --threads <parent>) <children>\r
  92 >\r
  93 > The bigger problem is that as soon as we have an operation to join\r
  94 > threads, people are going to need an operation to split threads. (And\r
  95 > some people want this already for cases where people reply when they\r
  96 > should have composed a new message.)\r
  97 >\r
  98 > The split case is harder in that it will require some extra stashing of\r
  99 > information about the intent of the split, (otherwise, the current logic\r
 100 > will recombine things when a future message arrives that References:\r
 101 > messages from two split threads).\r
 102 >\r
 103 > So I think we'd need a proposal to handle that before we could do\r
 104 > splitting. The proposal I'm looking for here would be at the database\r
 105 > level, not the command-line level.\r
 106 >\r
 107 > -Carl\r
 108 \r
 109 Here are some new thoughts on this today:\r
 110 \r
 111 The join case is easy. Simply expose the function above and then add a\r
 112 command like:\r
 113 \r
 114         notmuch join id:<one-message> id:<another-message>\r
 115 \r
 116 As I mentioned above, adding this command would almost force the\r
 117 addition of a "notmuch split" command as well, (even if only to undo an\r
 118 accidental join). We could easily implement a "notmuch split" that would\r
 119 function perfectly for undo:\r
 120 \r
 121         notmuch split id:<message-id>\r
 122         # Split <message-id> from its parent thread, making it a\r
 123         # top-level message in a new thread (with all of its existing\r
 124         # children)\r
 125 \r
 126 Without any additional "stashing of intent" this would work for the\r
 127 "undo of a join" operation, since those messages are inherently\r
 128 separate, (they don't have any common references). It wouldn't work well\r
 129 for splitting an originally intact thread since, (as I mentioned above),\r
 130 future messages could undo the split by triggering a _merge_threads\r
 131 call.\r
 132 \r
 133 But I suppose it's as simple a matter of creating a new "top-level\r
 134 message" term in the database. The split operation would set this\r
 135 term. The explicit join operation would clear it, and the implicit join\r
 136 operation would have to be made to respect it by avoiding merging any\r
 137 top-level messages as a child of some other message. I haven't thought\r
 138 through exactly how that would work in the implementation, but hopefully\r
 139 it wouldn't be too hard.\r
 140 \r
 141 Anyone interested in tackling this task? It might be interesting. :-)\r
 142 \r
 143 -Carl\r
 144 \r
 145 [*] To be strict here: In the common case, both children will reference\r
 146 a common message-ID and notmuch is clever enough to notice this and\r
 147 merge the children even before the parent arrives. But it's still\r
 148 possible to construct mails that start out in separate threads and later\r
 149 get merged when a common parent arrives.\r
 150 \r
 151 --=-=-=\r
 152 Content-Type: application/pgp-signature\r
 153 \r
 154 -----BEGIN PGP SIGNATURE-----\r
 155 Version: GnuPG v1.4.10 (GNU/Linux)\r
 156 \r
 157 iD8DBQFM3eXS6JDdNq8qSWgRAumcAJ9yEDl6p4UeMiPXH7D7t0ac7AX8xgCghbXC\r
 158 0iGPOwPYoVu3/RBHb5No//M=\r
 159 =z3El\r
 160 -----END PGP SIGNATURE-----\r
 161 --=-=-=--\r