Re: thread merge/split proposal

[Daniel Kahn Gillmor <dkg@fifthhorseman.net>]

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