a2/0758063525b25163f2e8c87a3cf2b2ef676259

   1 Return-Path: <dkg@fifthhorseman.net>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5  by arlo.cworth.org (Postfix) with ESMTP id F0C2A6DE012F\r
   6  for <notmuch@notmuchmail.org>; Mon, 11 Apr 2016 18:30:04 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at cworth.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.019\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.019 tagged_above=-999 required=5\r
  12  tests=[AWL=-0.019] autolearn=disabled\r
  13 Received: from arlo.cworth.org ([127.0.0.1])\r
  14  by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15  with ESMTP id aIuQcet-_0x3 for <notmuch@notmuchmail.org>;\r
  16  Mon, 11 Apr 2016 18:29:56 -0700 (PDT)\r
  17 Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118])\r
  18  by arlo.cworth.org (Postfix) with ESMTP id 7CFB06DE0159\r
  19  for <notmuch@notmuchmail.org>; Mon, 11 Apr 2016 18:29:56 -0700 (PDT)\r
  20 Received: from fifthhorseman.net (unknown [38.109.115.130])\r
  21  by che.mayfirst.org (Postfix) with ESMTPSA id 4CBEDF991;\r
  22  Mon, 11 Apr 2016 21:29:55 -0400 (EDT)\r
  23 Received: by fifthhorseman.net (Postfix, from userid 1000)\r
  24  id F22D820072; Mon, 11 Apr 2016 21:29:54 -0400 (EDT)\r
  25 From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>\r
  26 To: David Bremner <david@tethera.net>, Notmuch Mail <notmuch@notmuchmail.org>\r
  27 Subject: Re: thread merge/split proposal\r
  28 In-Reply-To: <8737qr7ig6.fsf@zancas.localnet>\r
  29 References: <87mvp9uwi4.fsf@alice.fifthhorseman.net>\r
  30  <87k2kdutao.fsf@alice.fifthhorseman.net> <878u0l8uyv.fsf@zancas.localnet>\r
  31  <87egabu5ta.fsf@alice.fifthhorseman.net> <8737qr7ig6.fsf@zancas.localnet>\r
  32 User-Agent: Notmuch/0.21+124~gbf604e9 (http://notmuchmail.org) Emacs/24.5.1\r
  33  (x86_64-pc-linux-gnu)\r
  34 Date: Mon, 11 Apr 2016 21:29:54 -0400\r
  35 Message-ID: <87d1pvsjfx.fsf@alice.fifthhorseman.net>\r
  36 MIME-Version: 1.0\r
  37 Content-Type: text/plain\r
  38 X-BeenThere: notmuch@notmuchmail.org\r
  39 X-Mailman-Version: 2.1.20\r
  40 Precedence: list\r
  41 List-Id: "Use and development of the notmuch mail system."\r
  42  <notmuch.notmuchmail.org>\r
  43 List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,\r
  44  <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  45 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
  46 List-Post: <mailto:notmuch@notmuchmail.org>\r
  47 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  48 List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
  49  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  50 X-List-Received-Date: Tue, 12 Apr 2016 01:30:05 -0000\r
  51 \r
  52 On Mon 2016-04-11 20:56:57 -0400, David Bremner wrote:\r
  53 > Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:\r
  54 >\r
  55 >> I'm not sure what you mean by "signed" here (cryptographically signed?\r
  56 >> a term named "signed"?  the idea that the term could be either positive\r
  57 >> or negative?), but i think your proposal is that we could have a\r
  58 >> "reference" term with a value of "+foo@example.com" or\r
  59 >> "-foo@example.com", instead of having a "join" term with value\r
  60 >> "foo@example.com" and a "split" term with value "foo@example.com"\r
  61 >\r
  62 > I was thinking mostly in terms of the UI. I think\r
  63 >\r
  64 > %  notmuch reference +id1 -id2 $QUERY\r
  65 >         \r
  66 > goes well with the tag interface.\r
  67 \r
  68 I see, yeah, that makes sense.\r
  69 \r
  70 That still doesn't cover the "notmuch unjoin" semantics i'd sketched out\r
  71 earlier, though.  that might need to be a different use case.\r
  72 \r
  73 The semantics would be something like:\r
  74 \r
  75   break the selected threads into threads based solely on their\r
  76   References headers (including any manual reference terms) using\r
  77   connected component analysis, restoring the threading to what would be\r
  78   produced on a clean import.\r
  79 \r
  80 maybe "unjoin" is the wrong verb, but i'm open to suggestions.\r
  81 \r
  82 > I'm a bit worried about UI proliferation with notmuch-join,\r
  83 > notmuch-unjoin now and maybe notmuch-split, notmuch-unsplit later. I'd\r
  84 > be fine with a more generic command with parts perhaps unimplimented.\r
  85 \r
  86 i see, that makes sense.\r
  87 \r
  88 > Making things generic in the right way will be less work in the long\r
  89 > run, I think.  For example, if we had thought about more general terms\r
  90 > attached to a message in the last revision of dump/restore, we'd be done\r
  91 > now. \r
  92 \r
  93 right -- we don't even have any version information in the notmuch dump\r
  94 file.  what's the right way to approach this?\r
  95 \r
  96        --dkg\r