unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
* Combining threads
@ 2010-11-12 16:57 Scott Henson
  2010-11-13  1:11 ` Carl Worth
  0 siblings, 1 reply; 8+ messages in thread
From: Scott Henson @ 2010-11-12 16:57 UTC (permalink / raw)
  To: notmuch

[-- 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 --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Combining threads
  2010-11-12 16:57 Combining threads Scott Henson
@ 2010-11-13  1:11 ` Carl Worth
  2010-11-13  2:20   ` splittng threads [was: Re: Combining threads] Daniel Kahn Gillmor
                     ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Carl Worth @ 2010-11-13  1:11 UTC (permalink / raw)
  To: Scott Henson, notmuch

[-- 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 --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* splittng threads [was: Re: Combining threads]
  2010-11-13  1:11 ` Carl Worth
@ 2010-11-13  2:20   ` Daniel Kahn Gillmor
  2010-11-14 22:24     ` Michal Sojka
  2010-11-14 22:21   ` Web archive (was: Combining threads) Michal Sojka
  2012-09-25 16:08   ` On splitting threads - Was: Re: Combining threads Olivier Berger
  2 siblings, 1 reply; 8+ messages in thread
From: Daniel Kahn Gillmor @ 2010-11-13  2:20 UTC (permalink / raw)
  To: notmuch

[-- 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 --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Web archive (was: Combining threads)
  2010-11-13  1:11 ` Carl Worth
  2010-11-13  2:20   ` splittng threads [was: Re: Combining threads] Daniel Kahn Gillmor
@ 2010-11-14 22:21   ` Michal Sojka
  2010-11-14 23:32     ` Jameson Rollins
  2012-09-25 16:08   ` On splitting threads - Was: Re: Combining threads Olivier Berger
  2 siblings, 1 reply; 8+ messages in thread
From: Michal Sojka @ 2010-11-14 22:21 UTC (permalink / raw)
  To: Carl Worth, Scott Henson, notmuch

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: splittng threads [was: Re: Combining threads]
  2010-11-13  2:20   ` splittng threads [was: Re: Combining threads] Daniel Kahn Gillmor
@ 2010-11-14 22:24     ` Michal Sojka
  2010-11-14 23:58       ` David Bremner
  0 siblings, 1 reply; 8+ messages in thread
From: Michal Sojka @ 2010-11-14 22:24 UTC (permalink / raw)
  To: Daniel Kahn Gillmor, notmuch

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Web archive (was: Combining threads)
  2010-11-14 22:21   ` Web archive (was: Combining threads) Michal Sojka
@ 2010-11-14 23:32     ` Jameson Rollins
  0 siblings, 0 replies; 8+ messages in thread
From: Jameson Rollins @ 2010-11-14 23:32 UTC (permalink / raw)
  To: Michal Sojka, Carl Worth, Scott Henson, notmuch

[-- 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 --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: splittng threads [was: Re: Combining threads]
  2010-11-14 22:24     ` Michal Sojka
@ 2010-11-14 23:58       ` David Bremner
  0 siblings, 0 replies; 8+ messages in thread
From: David Bremner @ 2010-11-14 23:58 UTC (permalink / raw)
  To: Michal Sojka, Daniel Kahn Gillmor, notmuch

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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* On splitting threads - Was: Re: Combining threads
  2010-11-13  1:11 ` Carl Worth
  2010-11-13  2:20   ` splittng threads [was: Re: Combining threads] Daniel Kahn Gillmor
  2010-11-14 22:21   ` Web archive (was: Combining threads) Michal Sojka
@ 2012-09-25 16:08   ` Olivier Berger
  2 siblings, 0 replies; 8+ messages in thread
From: Olivier Berger @ 2012-09-25 16:08 UTC (permalink / raw)
  To: notmuch

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)

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2012-09-25 16:10 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-11-12 16:57 Combining threads Scott Henson
2010-11-13  1:11 ` Carl Worth
2010-11-13  2:20   ` splittng threads [was: Re: Combining threads] Daniel Kahn Gillmor
2010-11-14 22:24     ` Michal Sojka
2010-11-14 23:58       ` David Bremner
2010-11-14 22:21   ` Web archive (was: Combining threads) Michal Sojka
2010-11-14 23:32     ` Jameson Rollins
2012-09-25 16:08   ` On splitting threads - Was: Re: Combining threads Olivier Berger

Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).