fe/38df325d7ce1e604aa64bc94cb1e5a433bf9ff

   1 Return-Path: <david@tethera.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 6DC386DE012F\r
   6  for <notmuch@notmuchmail.org>; Mon, 11 Apr 2016 17:57:07 -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.017\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.017 tagged_above=-999 required=5\r
  12  tests=[AWL=-0.006, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01]\r
  13  autolearn=disabled\r
  14 Received: from arlo.cworth.org ([127.0.0.1])\r
  15  by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16  with ESMTP id UBqTkRowV1aT for <notmuch@notmuchmail.org>;\r
  17  Mon, 11 Apr 2016 17:56:59 -0700 (PDT)\r
  18 Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197])\r
  19  by arlo.cworth.org (Postfix) with ESMTPS id A653F6DE0127\r
  20  for <notmuch@notmuchmail.org>; Mon, 11 Apr 2016 17:56:59 -0700 (PDT)\r
  21 Received: from remotemail by fethera.tethera.net with local (Exim 4.84)\r
  22  (envelope-from <david@tethera.net>)\r
  23  id 1apmdg-0003LR-28; Mon, 11 Apr 2016 20:57:08 -0400\r
  24 Received: (nullmailer pid 26271 invoked by uid 1000);\r
  25  Tue, 12 Apr 2016 00:56:57 -0000\r
  26 From: David Bremner <david@tethera.net>\r
  27 To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>,\r
  28  Notmuch Mail <notmuch@notmuchmail.org>\r
  29 Subject: Re: thread merge/split proposal\r
  30 In-Reply-To: <87egabu5ta.fsf@alice.fifthhorseman.net>\r
  31 References: <87mvp9uwi4.fsf@alice.fifthhorseman.net>\r
  32  <87k2kdutao.fsf@alice.fifthhorseman.net> <878u0l8uyv.fsf@zancas.localnet>\r
  33  <87egabu5ta.fsf@alice.fifthhorseman.net>\r
  34 User-Agent: Notmuch/0.21+99~gd93d377 (http://notmuchmail.org) Emacs/24.5.1\r
  35  (x86_64-pc-linux-gnu)\r
  36 Date: Mon, 11 Apr 2016 21:56:57 -0300\r
  37 Message-ID: <8737qr7ig6.fsf@zancas.localnet>\r
  38 MIME-Version: 1.0\r
  39 Content-Type: text/plain\r
  40 X-BeenThere: notmuch@notmuchmail.org\r
  41 X-Mailman-Version: 2.1.20\r
  42 Precedence: list\r
  43 List-Id: "Use and development of the notmuch mail system."\r
  44  <notmuch.notmuchmail.org>\r
  45 List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,\r
  46  <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  47 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
  48 List-Post: <mailto:notmuch@notmuchmail.org>\r
  49 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  50 List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
  51  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  52 X-List-Received-Date: Tue, 12 Apr 2016 00:57:07 -0000\r
  53 \r
  54 Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:\r
  55 \r
  56 > I'm not sure what you mean by "signed" here (cryptographically signed?\r
  57 > a term named "signed"?  the idea that the term could be either positive\r
  58 > or negative?), but i think your proposal is that we could have a\r
  59 > "reference" term with a value of "+foo@example.com" or\r
  60 > "-foo@example.com", instead of having a "join" term with value\r
  61 > "foo@example.com" and a "split" term with value "foo@example.com"\r
  62 \r
  63 I was thinking mostly in terms of the UI. I think\r
  64 \r
  65 %  notmuch reference +id1 -id2 $QUERY\r
  66         \r
  67 goes well with the tag interface.\r
  68 \r
  69 > I'm not sure i see much of a difference between\r
  70 >\r
  71 >  a) introduce two new term types, "join" and "split", with unsigned\r
  72 >     values\r
  73 > and\r
  74 >\r
  75 >  b) introduce one new term type, "reference" with signed values\r
  76 \r
  77 Yeah, it's an implimentation detail, not clear to me that it matters.\r
  78 \r
  79 > both (a) and (b) complicate syncing solutions, but my original proposal\r
  80 > of:\r
  81 >\r
  82 >  c) just introduce a new term type "join" with unsigned value\r
  83 \r
  84 I just meant it isn't representable as folders, like tags are (not well,\r
  85 but *shrug*).\r
  86 \r
  87 > is easy to sync, i think; i was going for the low-hanging fruit, and\r
  88 > trying to not let it get caught up on the more-fully-featured\r
  89 > arbitrary-split use case, though i understand the appeal of the generic\r
  90 > approach.\r
  91 \r
  92 I'm a bit worried about UI proliferation with notmuch-join,\r
  93 notmuch-unjoin now and maybe notmuch-split, notmuch-unsplit later. I'd\r
  94 be fine with a more generic command with parts perhaps unimplimented.\r
  95  \r
  96 > So adding an explicit "join" document term (and figuring out how to\r
  97 > represent it in "notmuch dump" and "notmuch restore") would be a strict\r
  98 > improvement over the current situation, right?\r
  99 \r
 100 Making things generic in the right way will be less work in the long\r
 101 run, I think.  For example, if we had thought about more general terms\r
 102 attached to a message in the last revision of dump/restore, we'd be done\r
 103 now. \r