thread merge/split proposal
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Mon Apr 11 18:29:54 PDT 2016
On Mon 2016-04-11 20:56:57 -0400, David Bremner wrote:
> Daniel Kahn Gillmor <dkg at 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 at example.com" or
>> "-foo at example.com", instead of having a "join" term with value
>> "foo at example.com" and a "split" term with value "foo at 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
More information about the notmuch
mailing list