6c/acd0e7a9da4484d8b9e7736a258e99463f814c

   1 Return-Path: <amdragon@mit.edu>\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 olra.theworths.org (Postfix) with ESMTP id 85F71431FBD\r
   6         for <notmuch@notmuchmail.org>; Tue,  4 Feb 2014 12:03:02 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.7\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
  12         tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id kVDQK1MIWEbS for <notmuch@notmuchmail.org>;\r
  16         Tue,  4 Feb 2014 12:02:57 -0800 (PST)\r
  17 Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu\r
  18         [18.7.68.36])\r
  19         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
  20         (No client certificate requested)\r
  21         by olra.theworths.org (Postfix) with ESMTPS id D255B431FBC\r
  22         for <notmuch@notmuchmail.org>; Tue,  4 Feb 2014 12:02:56 -0800 (PST)\r
  23 X-AuditID: 12074424-f79e26d000000c70-9c-52f1476fe34b\r
  24 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36])\r
  25         (using TLS with cipher AES256-SHA (256/256 bits))\r
  26         (Client did not present a certificate)\r
  27         by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP\r
  28         id C1.59.03184.F6741F25; Tue,  4 Feb 2014 15:02:55 -0500 (EST)\r
  29 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])\r
  30         by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s14K2sQS010802; \r
  31         Tue, 4 Feb 2014 15:02:55 -0500\r
  32 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91])\r
  33         (authenticated bits=0)\r
  34         (User authenticated as amdragon@ATHENA.MIT.EDU)\r
  35         by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s14K2pMJ011859\r
  36         (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);\r
  37         Tue, 4 Feb 2014 15:02:53 -0500\r
  38 Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.80)\r
  39         (envelope-from <amdragon@mit.edu>)\r
  40         id 1WAmCo-000142-PD; Tue, 04 Feb 2014 15:02:50 -0500\r
  41 Date: Tue, 4 Feb 2014 15:02:50 -0500\r
  42 From: Austin Clements <amdragon@MIT.EDU>\r
  43 To: Jani Nikula <jani@nikula.org>\r
  44 Subject: Re: [PATCH 0/5] lib: make folder: prefix literal\r
  45 Message-ID: <20140204200249.GO4375@mit.edu>\r
  46 References: <cover.1389304779.git.jani@nikula.org>\r
  47         <87y525m649.fsf@awakening.csail.mit.edu>\r
  48         <87r47wfltb.fsf@nikula.org> <87iot8f4vg.fsf@nikula.org>\r
  49         <20140130220234.GI4375@mit.edu> <87fvo2yjc4.fsf@nikula.org>\r
  50 MIME-Version: 1.0\r
  51 Content-Type: text/plain; charset=us-ascii\r
  52 Content-Disposition: inline\r
  53 In-Reply-To: <87fvo2yjc4.fsf@nikula.org>\r
  54 User-Agent: Mutt/1.5.21 (2010-09-15)\r
  55 X-Brightmail-Tracker:\r
  56  H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IRYrdT0c13/xhk0LbEwKJpurPF9ZszmR2Y\r
  57         PG7df83u8WzVLeYApigum5TUnMyy1CJ9uwSujGU7z7EVvJSp2PDhEFsD406xLkZODgkBE4nG\r
  58         Y4cYIWwxiQv31rN1MXJxCAnMZpKY0LyDBcLZwCgxa0YXK4Rzikmic8p6VpAWIYEljBLTr+WC\r
  59         2CwCKhJ90zvA4mwCGhLb9i8HGysioCix+eR+MJtZQFri2+9mJhBbWMBSYuqdKWA2r4C2xPHf\r
  60         t6BW32SU6L9+mAUiIShxcuYTFohmLYkb/14CNXCADVr+jwMkzAm068GmbWB7RYFumHJyG9sE\r
  61         RqFZSLpnIemehdC9gJF5FaNsSm6Vbm5iZk5xarJucXJiXl5qka65Xm5miV5qSukmRnBYu6js\r
  62         YGw+pHSIUYCDUYmHt0P0Y5AQa2JZcWXuIUZJDiYlUd4rDkAhvqT8lMqMxOKM+KLSnNTiQ4wS\r
  63         HMxKIrxmnz8ECfGmJFZWpRblw6SkOViUxHkTZ7wJEhJITyxJzU5NLUgtgsnKcHAoSfC2uQEN\r
  64         FSxKTU+tSMvMKUFIM3FwggznARoeAVLDW1yQmFucmQ6RP8WoKCXOawySEABJZJTmwfXC0s4r\r
  65         RnGgV4R5K0GqeIApC677FdBgJqDB61zfgwwuSURISTUw5h3YYuDOtSxTd/USFePmYs7GgLT1\r
  66         F/dM0+J8w8Pd4ulyQ7pg2r8FTTrsd0OETeScJjGd1K9ZbL7V0VK1REZ7o2b+z3sact7vZiqk\r
  67         GNQL8Gpn1OwUKpqrWP4q8dkFmdvfd9nqbXSo5nn74c7i+RX+c479TCs15/ONL5oQKvie5Xw2\r
  68         1/rpi02UWIozEg21mIuKEwFgAnBJFgMAAA==\r
  69 Cc: notmuch@notmuchmail.org\r
  70 X-BeenThere: notmuch@notmuchmail.org\r
  71 X-Mailman-Version: 2.1.13\r
  72 Precedence: list\r
  73 List-Id: "Use and development of the notmuch mail system."\r
  74         <notmuch.notmuchmail.org>\r
  75 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  76         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  77 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  78 List-Post: <mailto:notmuch@notmuchmail.org>\r
  79 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  80 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  81         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  82 X-List-Received-Date: Tue, 04 Feb 2014 20:03:02 -0000\r
  83 \r
  84 Quoth Jani Nikula on Feb 01 at  4:54 pm:\r
  85 > On Fri, 31 Jan 2014, Austin Clements <amdragon@MIT.EDU> wrote:\r
  86 > > What if we introduce two prefixes, say folder: and path: (maybe dir:?)\r
  87 > > to address both use cases, each as naturally as possible?  Both would\r
  88 > > be boolean prefixes because of the limitations of probabilistic\r
  89 > > prefixes, but we could take advantage of Jani's idea of generating\r
  90 > > several boolean terms.\r
  91 > \r
  92 > Agreed. On to details:\r
  93 > \r
  94 > > folder: could work the way I suggested (simply the path to the file,\r
  95 > > with {cur,new} stripped off).\r
  96 > \r
  97 > What if the file is not in a folder named cur/new? I suggest indexing\r
  98 > the folder as-is, if only for some backwards compatibility.\r
  99 \r
 100 Agreed.  I believe this will also support MH, if I understand MH\r
 101 correctly (does anyone actually use MH?)\r
 102 \r
 103 > What if there is not all of cur/new/tmp folders? I suggest ignoring\r
 104 > that, and only look at the path to the file being indexed. This is\r
 105 > simplest to implement, and it does not matter if the sibling directories\r
 106 > come and go, and for this reason also unsurprising.\r
 107 \r
 108 That sounds good to me.\r
 109 \r
 110 > For top level cur/new, index the empty string "".\r
 111 \r
 112 Yes.\r
 113 \r
 114 > > path: would support file system search\r
 115 > > uses.  These seem more varied, but I think fall into exact match and\r
 116 > > recursive match.  Since I don't have this use case, I can't have any\r
 117 > > strong opinions about syntax, but I'll throw out an idea: many shells\r
 118 > > support "**" for recursive path matching and people are already quite\r
 119 > > familiar with glob patterns for paths, so why not simply adopt this?\r
 120 > > In other words, when adding the path "a/b/cur/x:2," add path: terms\r
 121 > > "a/b/cur" and "a/b/**" and "a/**" and "**".\r
 122 > \r
 123 > Since folder: would cover the cur/new cases, I suggest the non-recursive\r
 124 > variant of path: prefix is the exact filesystem folder name as-is (with\r
 125 > the top level being the empty string ""). I presume this is what you\r
 126 > meant too.\r
 127 \r
 128 Yes.  I suppose I didn't actually say it, but that's what I was\r
 129 thinking.\r
 130 \r
 131 > I kind of like the "/**" suffix for recursive, but there's two small\r
 132 > wrinkles: 1) it needs quoting on the command line (unlike my original\r
 133 > suggestion of just "/" suffix), and 2) what should the top level\r
 134 > recursive search be? path:"**" or path:"/**" or path:"./**"? I guess the\r
 135 > first one is most obvious?\r
 136 \r
 137 The shell quoting is annoying, but depending on the shell, it should\r
 138 at least give an error (zsh) or Just Work (apparently bash and sh pass\r
 139 the unexpanded glob through if it doesn't match anything?).\r
 140 \r
 141 > So here's what my original suggestions would become:\r
 142 > \r
 143 > >> Here's a thought. With boolean prefix folder:, we can devise a scheme\r
 144 > >> where the folder: query defines what is to be matched.\r
 145 > >> \r
 146 > >> For example:\r
 147 > >> \r
 148 > >> folder:foo match files in foo, foo/new, and foo/cur.\r
 149 > \r
 150 > -> folder:foo\r
 151 > \r
 152 > >> folder:foo/        match all files in all subdirectories under foo (this\r
 153 > >>            would handle Tomi's use case), including foo/new and foo/cur.\r
 154 > \r
 155 > -> path:"foo/**"\r
 156 > \r
 157 > >> folder:foo/.       match in foo only, and specifically not in foo/cur or foo/new.\r
 158 > \r
 159 > -> path:foo\r
 160 > \r
 161 > >> folder:foo/new  match in foo/new, and specifically not in foo/cur (this\r
 162 > >>            allows distinguishing between messages in cur and new).\r
 163 > \r
 164 > -> path:foo/new\r
 165 > \r
 166 > >> folder:/   match everything.\r
 167 > \r
 168 > -> path:"**"\r
 169 > \r
 170 > >> folder:/.  match in top level maildir only.\r
 171 > \r
 172 > -> path:""\r
 173 > \r
 174 > >> folder:""  match in top level maildir, including cur/new.\r
 175 > \r
 176 > -> folder:""\r
 177 > \r
 178 > \r
 179 > I'd like these details to be ironed out and agreed on before I send the\r
 180 > next version.\r
 181 \r
 182 This all looks good to me.\r
 183 \r
 184 > BR,\r
 185 > Jani.\r