From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: David Bremner <david@tethera.net>, Notmuch Mail <notmuch@notmuchmail.org>
Subject: Re: thread merge/split proposal
In-Reply-To: <8737qr7ig6.fsf@zancas.localnet>
References: <87mvp9uwi4.fsf@alice.fifthhorseman.net>
 <87k2kdutao.fsf@alice.fifthhorseman.net> <878u0l8uyv.fsf@zancas.localnet>
 <87egabu5ta.fsf@alice.fifthhorseman.net> <8737qr7ig6.fsf@zancas.localnet>
User-Agent: Notmuch/0.21+124~gbf604e9 (http://notmuchmail.org) Emacs/24.5.1
 (x86_64-pc-linux-gnu)
Date: Mon, 11 Apr 2016 21:29:54 -0400
Message-ID: <87d1pvsjfx.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list

On Mon 2016-04-11 20:56:57 -0400, David Bremner wrote:
> Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:
>
>> I'm not sure what you mean by "signed" here (cryptographically signed?
>> a term named "signed"?  the idea that the term could be either positive
>> or negative?), but i think your proposal is that we could have a
>> "reference" term with a value of "+foo@example.com" or
>> "-foo@example.com", instead of having a "join" term with value
>> "foo@example.com" and a "split" term with value "foo@example.com"
>
> I was thinking mostly in terms of the UI. I think
>
> %  notmuch reference +id1 -id2 $QUERY
>         
> goes well with the tag interface.

I see, yeah, that makes sense.

That still doesn't cover the "notmuch unjoin" semantics i'd sketched out
earlier, though.  that might need to be a different use case.

The semantics would be something like:

  break the selected threads into threads based solely on their
  References headers (including any manual reference terms) using
  connected component analysis, restoring the threading to what would be
  produced on a clean import.

maybe "unjoin" is the wrong verb, but i'm open to suggestions.

> I'm a bit worried about UI proliferation with notmuch-join,
> notmuch-unjoin now and maybe notmuch-split, notmuch-unsplit later. I'd
> be fine with a more generic command with parts perhaps unimplimented.

i see, that makes sense.

> Making things generic in the right way will be less work in the long
> run, I think.  For example, if we had thought about more general terms
> attached to a message in the last revision of dump/restore, we'd be done
> now. 

right -- we don't even have any version information in the notmuch dump
file.  what's the right way to approach this?

       --dkg