5c/f9bf2a3effe4905b20838252d1e0881a1a79c3

   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 3B4536DE0274\r
   6  for <notmuch@notmuchmail.org>; Sun, 10 Jan 2016 05:59:35 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at cworth.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.31\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[AWL=0.241, \r
  12  RP_MATCHES_RCVD=-0.55, SPF_PASS=-0.001] 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 rsxUSEUFlrar for <notmuch@notmuchmail.org>;\r
  16  Sun, 10 Jan 2016 05:59:33 -0800 (PST)\r
  17 Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197])\r
  18  by arlo.cworth.org (Postfix) with ESMTPS id 427276DE0261\r
  19  for <notmuch@notmuchmail.org>; Sun, 10 Jan 2016 05:59:33 -0800 (PST)\r
  20 Received: from remotemail by fethera.tethera.net with local (Exim 4.84)\r
  21  (envelope-from <david@tethera.net>)\r
  22  id 1aIGWe-0006rI-NR; Sun, 10 Jan 2016 08:59:20 -0500\r
  23 Received: (nullmailer pid 8729 invoked by uid 1000);\r
  24  Sun, 10 Jan 2016 13:59:28 -0000\r
  25 From: David Bremner <david@tethera.net>\r
  26 To: Igor Almeida <igor.contato@gmail.com>, notmuch@notmuchmail.org\r
  27 Subject: Re: [PATCH/RFC 0/3] Maildir custom flags and notmuch tags\r
  28 In-Reply-To: <1448504191-30974-1-git-send-email-igor.contato@gmail.com>\r
  29 References: <1448504191-30974-1-git-send-email-igor.contato@gmail.com>\r
  30 User-Agent: Notmuch/0.21+26~g9404723 (http://notmuchmail.org) Emacs/24.5.1\r
  31  (x86_64-pc-linux-gnu)\r
  32 Date: Sun, 10 Jan 2016 09:59:28 -0400\r
  33 Message-ID: <87mvsd7cxr.fsf@zancas.localnet>\r
  34 MIME-Version: 1.0\r
  35 Content-Type: text/plain\r
  36 X-BeenThere: notmuch@notmuchmail.org\r
  37 X-Mailman-Version: 2.1.20\r
  38 Precedence: list\r
  39 List-Id: "Use and development of the notmuch mail system."\r
  40  <notmuch.notmuchmail.org>\r
  41 List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,\r
  42  <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  43 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
  44 List-Post: <mailto:notmuch@notmuchmail.org>\r
  45 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  46 List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
  47  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  48 X-List-Received-Date: Sun, 10 Jan 2016 13:59:35 -0000\r
  49 \r
  50 Igor Almeida <igor.contato@gmail.com> writes:\r
  51 \r
  52 > Building on Bremner's patch at\r
  53 > <1411805835-3563-1-git-send-email-david@tethera.net>, this updates\r
  54 > 'notmuch new' to tag messages based on lower-case letters in the file\r
  55 > name.\r
  56 > I'm testing this with an IMAP server, offlineimap and notmuch,\r
  57 > and seems to work well enough for my unidirectional use case.\r
  58 > Eventually I'd like to implement the reverse path, i.e. tagging in\r
  59 > notmuch and seeing IMAP keywords show up in the server, but that's for\r
  60 > later.\r
  61 >\r
  62 > Comments are very welcome.\r
  63 >\r
  64 \r
  65 Sorry about the long silence. I _have_ been thinking about and working\r
  66 on this. This message summarizes my current thinking/plan.\r
  67 \r
  68 I'm not very enthusiastic about the about the several places this can\r
  69 get out of sync\r
  70 \r
  71 1) config info in .notmuch-config can be out of sync with the "real\r
  72 config" in the database.  This part is only until the next run of\r
  73 notmuch new, so it's not so bad.\r
  74 \r
  75 2) When the interpretation of maildir flags changes, there doesn't seem\r
  76 to be a sensible way of retagging messages.\r
  77 \r
  78 Some others have objected to supporting a nonstandard extension used (I\r
  79 think) only by dovecot. For me this is not so bad, as long as the code\r
  80 required specifically for this is not too large / intrusive.\r
  81 \r
  82 So here are the pieces I think we need. \r
  83 \r
  84 a) some code in notmuch-new to sync flags a-z to a fixed set of tags\r
  85   [1]. This soundspretty much the functionality you have now, although I\r
  86   haven't really reviewed that part of the series.\r
  87 \r
  88 b) some code to update metadata directly from the CLI (notmuch\r
  89    config/notmuch tag), probably using something like [2] as a back\r
  90    end. This metadata maps the fixed tags like $maildir_flag_k to and\r
  91    from some friendly format.\r
  92 \r
  93 c) The use of xapian field processors to translate e.g. a query\r
  94    "tag:my-sensible-thing" into "tag:$maildir_flag_k". Optionally do the\r
  95    reverse when returning lists of tags. FieldProcessors are only\r
  96    available in Xapian 1.3.x, but apparently 1.3 series is nearing a\r
  97    stable release, so it's a sane time to optionally depend on it.\r
  98    I guess as a short term hack, this could be done by shell wrappers\r
  99    (not something we'd ship, but it might make it usable for you).          \r
 100 \r
 101 d) code to dump and restore the metadata as part of the normal dump\r
 102    files. This is at least in progress [2].\r
 103 \r
 104 In terms of how these changes relate to other goals\r
 105 \r
 106 b,d) have strong connects with allowing database level config. Among\r
 107      other reasons this will help make bindings users less second class\r
 108      citizens\r
 109       \r
 110 \r
 111   c) has overlap with allowing date fields that are not ranges (among\r
 112      other things). At least all the machinery to configure xapian 1.2\r
 113      versus 1.3, and the understanding how to use field processors, is\r
 114      reusable.\r
 115 \r
 116 I'd understand perfectly if you prefer to rebase your simpler solution\r
 117 on top of master, but if you want to keep working on this, then I guess\r
 118 (a), (b), and (c) are all things you would work on.\r
 119 \r
 120 Probably (b) needs the library api from [2], which now that I start\r
 121 typing this epic long message, I could split off from the dump/restore\r
 122 stuff. In particular managing the config metadata only needs about half\r
 123 of the LOC; the iterator is only needed for dump, I think.\r
 124 \r
 125 David\r
 126 \r
 127 [1]: eventually it might make sense to split the tags that are somehow\r
 128 automatic from those that represent user choice. We already have this\r
 129 issue with tag:encrypted and friends.\r
 130 \r
 131 [2]: id:1452394301-29499-1-git-send-email-david@tethera.net\r