Re: thread merge/split proposal

[David Bremner <david@tethera.net>]

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'm not sure i see much of a difference between
>
>  a) introduce two new term types, "join" and "split", with unsigned
>     values
> and
>
>  b) introduce one new term type, "reference" with signed values

Yeah, it's an implimentation detail, not clear to me that it matters.

> both (a) and (b) complicate syncing solutions, but my original proposal
> of:
>
>  c) just introduce a new term type "join" with unsigned value

I just meant it isn't representable as folders, like tags are (not well,
but *shrug*).

> is easy to sync, i think; i was going for the low-hanging fruit, and
> trying to not let it get caught up on the more-fully-featured
> arbitrary-split use case, though i understand the appeal of the generic
> approach.

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.
 
> So adding an explicit "join" document term (and figuring out how to
> represent it in "notmuch dump" and "notmuch restore") would be a strict
> improvement over the current situation, right?

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.