Combining threads

[Carl Worth]

On Fri, 12 Nov 2010 08:57:21 -0800, Scott Henson <scott at foolishpride.org> 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 at 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 <aep at exys.org> 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 <parent>) <children>
>
> 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:<one-message> id:<another-message>

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:<message-id>
	# Split <message-id> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20101112/11f267d1/attachment.pgp>