Combining threads

Combining threads

[Scott Henson]

[-- Attachment #1: Type: text/plain, Size: 300 bytes --]

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?

-- 
Scott Henson

[-- Attachment #2: Type: text/html, Size: 328 bytes --]

Re: Combining threads

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 4275 bytes --]

On Fri, 12 Nov 2010 08:57:21 -0800, Scott Henson <scott@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@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@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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

splittng threads [was: Re: Combining threads]

[Daniel Kahn Gillmor]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

(hi list -- i'm new here; don't be afraid to explain things to me that
seem obvious to you, or correct my vocabulary if i'm using it wrong)

On 11/12/2010 08:11 PM, Carl Worth wrote:
> 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.

my current understanding is that a not-uncommon use case is to have two
separate notmuch instances, synchronized by syncing maildirs and
tagsets.  Would such a thread-split be syncable between two notmuch
instances?

	--dkg


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: splittng threads [was: Re: Combining threads]

[Michal Sojka]

On Sat, 13 Nov 2010, Daniel Kahn Gillmor wrote:
> (hi list -- i'm new here; don't be afraid to explain things to me that
> seem obvious to you, or correct my vocabulary if i'm using it wrong)
> 
> On 11/12/2010 08:11 PM, Carl Worth wrote:
> > 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.
> 
> my current understanding is that a not-uncommon use case is to have two
> separate notmuch instances, synchronized by syncing maildirs and
> tagsets.  Would such a thread-split be syncable between two notmuch
> instances?

It won't be syncable without a special support somewhere in notmuch.

-Michal

Re: splittng threads [was: Re: Combining threads]

[David Bremner]

On Sun, 14 Nov 2010 23:24:09 +0100, Michal Sojka <sojkam1@fel.cvut.cz> wrote:
> On Sat, 13 Nov 2010, Daniel Kahn Gillmor wrote:
> > my current understanding is that a not-uncommon use case is to have two
> > separate notmuch instances, synchronized by syncing maildirs and
> > tagsets.  Would such a thread-split be syncable between two notmuch
> > instances?
> 
> It won't be syncable without a special support somewhere in notmuch.
> 

To elaborate, threads are currently reconstructed in every instance
rather than being syncable. This is mainly because the thread-ids are
generated sequentially. Since messages could arrive in different
instances at different times, assigning the "right" thread-id is a bit
non-trivial.

Web archive (was: Combining threads)

[Michal Sojka]

On Sat, 13 Nov 2010, Carl Worth wrote:
> 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:

Gmane is not good? I'm quite satisfied with the following in my .emacs:

(defun notmuch-show-stash-gmane ()
  "Copy a link to gmane archive of the current message to kill-ring."
  (interactive)
  (notmuch-common-do-stash
   (concat "http://mid.gmane.org/"
	   (replace-regexp-in-string
	    "^id:\"\\(.*\\)\"$" "\\1" (notmuch-show-get-message-id))))))

(add-hook 'notmuch-show-hook
	  (lambda () 
	    (define-key notmuch-show-stash-map "g" 'notmuch-show-stash-gmane)))

-Michal

Re: Web archive (was: Combining threads)

[Jameson Rollins]

[-- Attachment #1: Type: text/plain, Size: 848 bytes --]

On Sun, 14 Nov 2010 23:21:26 +0100, Michal Sojka <sojkam1@fel.cvut.cz> wrote:
> Gmane is not good? I'm quite satisfied with the following in my .emacs:
> 
> (defun notmuch-show-stash-gmane ()
>   "Copy a link to gmane archive of the current message to kill-ring."
>   (interactive)
>   (notmuch-common-do-stash
>    (concat "http://mid.gmane.org/"
> 	   (replace-regexp-in-string
> 	    "^id:\"\\(.*\\)\"$" "\\1" (notmuch-show-get-message-id))))))
> 

Hey, Michal.  Nice tip.

> (add-hook 'notmuch-show-hook
> 	  (lambda () 
> 	    (define-key notmuch-show-stash-map "g" 'notmuch-show-stash-gmane)))

For what it's worth, I think you can accomplish this my simply adding
the following to your emacs config (assuming you've already loaded
notmuch):

(define-key notmuch-show-stash-map "g" 'notmuch-show-stash-gmane)

jamie.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

On splitting threads - Was: Re: Combining threads

[Olivier Berger]

Hi.

Carl Worth <cworth@cworth.org> writes:

> On Fri, 12 Nov 2010 08:57:21 -0800, Scott Henson <scott@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?
>

>> 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.)
>>

Also in the context of
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688699, I should say I'd
welcome a thread split feature for such cases too.

FWIW, hope this helps.

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)