From: David Bremner <david@tethera.net>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>,
 Notmuch Mail <notmuch@notmuchmail.org>
Subject: Re: thread merge/split proposal
In-Reply-To: <87egabu5ta.fsf@alice.fifthhorseman.net>
References: <87mvp9uwi4.fsf@alice.fifthhorseman.net>
 <87k2kdutao.fsf@alice.fifthhorseman.net> <878u0l8uyv.fsf@zancas.localnet>
 <87egabu5ta.fsf@alice.fifthhorseman.net>
User-Agent: Notmuch/0.21+99~gd93d377 (http://notmuchmail.org) Emacs/24.5.1
 (x86_64-pc-linux-gnu)
Date: Mon, 11 Apr 2016 21:56:57 -0300
Message-ID: <8737qr7ig6.fsf@zancas.localnet>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list

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.