From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 6ED0840DDE8 for ; Fri, 12 Nov 2010 17:11:59 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -2.89 X-Spam-Level: X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, T_MIME_NO_TEXT=0.01] autolearn=ham Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ku4ar9RbK-PZ; Fri, 12 Nov 2010 17:11:47 -0800 (PST) Received: from yoom.home.cworth.org (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 2A46F40DDCB; Fri, 12 Nov 2010 17:11:47 -0800 (PST) Received: by yoom.home.cworth.org (Postfix, from userid 1000) id C8E9B25412B; Fri, 12 Nov 2010 17:11:46 -0800 (PST) From: Carl Worth To: Scott Henson , notmuch Subject: Re: Combining threads In-Reply-To: References: User-Agent: Notmuch/0.4 (http://notmuchmail.org) Emacs/23.2.1 (i486-pc-linux-gnu) Date: Fri, 12 Nov 2010 17:11:46 -0800 Message-ID: <87mxpe81t9.fsf@yoom.home.cworth.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 01:11:59 -0000 --=-=-= On Fri, 12 Nov 2010 08:57:21 -0800, Scott Henson wrote: > Sometimes I get email from people with broken email clients that seem to > break threading. I remember that sup had a method of combining two threads > into one. Does notmuch have a similar feature? Is it even possible to > force it to glue two threads together and treat them as one? There's no support for this in the command-line interface, nor even the library interface. But internally in the implementation there is a function that joins two threads together. It looks like this: static notmuch_status_t _merge_threads (notmuch_database_t *notmuch, const char *winner_thread_id, const char *loser_thread_id); This function is used regularly---for example, when two child messages arrive separately and each get their own thread[*], then later the parent arrives. At that point the two threads are merged with the above function. Now, if we did have good support for thread joining I could join your request with the reply I gave the last time the question came up. ;-) That was in this email: id:87vd4k6956.fsf@yoom.home.cworth.org And since we don't yet have a good web-based archive that lets you just plug in message IDs, I'll quote my reply here: > On Sat, 08 May 2010 14:36:26 +0200, Arvid Picciani wrote: > > Most of my mail comes from the 50MLs i'm subscribed to. Unfortunately > > some MUAs suck that much, they don't even respond in threads. > > My idea how to fix them would be: > > People have previously asked for a feature to combine messages into the > same thread. > > And it would actually be a fairly simple operation. Perhaps it could be > something like: > > notmuch set-thread $(notmuch search --threads ) > > The bigger problem is that as soon as we have an operation to join > threads, people are going to need an operation to split threads. (And > some people want this already for cases where people reply when they > should have composed a new message.) > > The split case is harder in that it will require some extra stashing of > information about the intent of the split, (otherwise, the current logic > will recombine things when a future message arrives that References: > messages from two split threads). > > So I think we'd need a proposal to handle that before we could do > splitting. The proposal I'm looking for here would be at the database > level, not the command-line level. > > -Carl Here are some new thoughts on this today: The join case is easy. Simply expose the function above and then add a command like: notmuch join id: id: As I mentioned above, adding this command would almost force the addition of a "notmuch split" command as well, (even if only to undo an accidental join). We could easily implement a "notmuch split" that would function perfectly for undo: notmuch split id: # Split from its parent thread, making it a # top-level message in a new thread (with all of its existing # children) Without any additional "stashing of intent" this would work for the "undo of a join" operation, since those messages are inherently separate, (they don't have any common references). It wouldn't work well for splitting an originally intact thread since, (as I mentioned above), future messages could undo the split by triggering a _merge_threads call. But I suppose it's as simple a matter of creating a new "top-level message" term in the database. The split operation would set this term. The explicit join operation would clear it, and the implicit join operation would have to be made to respect it by avoiding merging any top-level messages as a child of some other message. I haven't thought through exactly how that would work in the implementation, but hopefully it wouldn't be too hard. Anyone interested in tackling this task? It might be interesting. :-) -Carl [*] To be strict here: In the common case, both children will reference a common message-ID and notmuch is clever enough to notice this and merge the children even before the parent arrives. But it's still possible to construct mails that start out in separate threads and later get merged when a common parent arrives. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFM3eXS6JDdNq8qSWgRAumcAJ9yEDl6p4UeMiPXH7D7t0ac7AX8xgCghbXC 0iGPOwPYoVu3/RBHb5No//M= =z3El -----END PGP SIGNATURE----- --=-=-=--