f5/bf1248a825f3f3217ba159ce9bd438028d296b

   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 5FA8F431FB6\r
   6         for <notmuch@notmuchmail.org>; Thu, 30 Jan 2014 14:02:47 -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 gykcxSB7ztQl for <notmuch@notmuchmail.org>;\r
  16         Thu, 30 Jan 2014 14:02:41 -0800 (PST)\r
  17 Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu\r
  18         [18.7.68.37])\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 66F21431FBD\r
  22         for <notmuch@notmuchmail.org>; Thu, 30 Jan 2014 14:02:41 -0800 (PST)\r
  23 X-AuditID: 12074425-f79906d000000cf9-1b-52eacc005076\r
  24 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35])\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-8.mit.edu (Symantec Messaging Gateway) with SMTP\r
  28         id 9A.BD.03321.00CCAE25; Thu, 30 Jan 2014 17:02:40 -0500 (EST)\r
  29 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])\r
  30         by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s0UM2cxg030481; \r
  31         Thu, 30 Jan 2014 17:02:39 -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 s0UM2ZtW008034\r
  36         (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);\r
  37         Thu, 30 Jan 2014 17:02:37 -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 1W8zgx-0007d3-7K; Thu, 30 Jan 2014 17:02:35 -0500\r
  41 Date: Thu, 30 Jan 2014 17:02:34 -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: <20140130220234.GI4375@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 MIME-Version: 1.0\r
  50 Content-Type: text/plain; charset=us-ascii\r
  51 Content-Disposition: inline\r
  52 In-Reply-To: <87iot8f4vg.fsf@nikula.org>\r
  53 User-Agent: Mutt/1.5.21 (2010-09-15)\r
  54 X-Brightmail-Tracker:\r
  55  H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IR4hRV1mU48yrIYN9eCYum6c4W12/OZHZg\r
  56         8rh1/zW7x7NVt5gDmKK4bFJSczLLUov07RK4Mh7t3M1WsFSyYvpb3wbGbSJdjJwcEgImEid/\r
  57         T2eHsMUkLtxbz9bFyMUhJDCbSeLihzcsEM5GRolF77awQjinmSRm/9rCDuEsYZRY23eNCaSf\r
  58         RUBVYlnbHVYQm01AQ2Lb/uWMILaIgKLE5pP7wWxmAWmJb7+bweqFBSwlpt6ZAmbzCmhLLLw5\r
  59         H2roTEaJGR0XmCESghInZz5hgWjWkrjx7yVQAwfYoOX/OEDCnEC7Vu1vBysXFVCRmHJyG9sE\r
  60         RqFZSLpnIemehdC9gJF5FaNsSm6Vbm5iZk5xarJucXJiXl5qka6FXm5miV5qSukmRlBYs7uo\r
  61         7mCccEjpEKMAB6MSD++MtFdBQqyJZcWVuYcYJTmYlER53+0CCvEl5adUZiQWZ8QXleakFh9i\r
  62         lOBgVhLhfd8PlONNSaysSi3Kh0lJc7AoifPe4rAPEhJITyxJzU5NLUgtgsnKcHAoSfB+OQXU\r
  63         KFiUmp5akZaZU4KQZuLgBBnOAzSc6zTI8OKCxNzizHSI/ClGRSlx3h0gzQIgiYzSPLheWNp5\r
  64         xSgO9Iow7z+QKh5gyoLrfgU0mAlosFY52OCSRISUVANjoNWDfbO5DLtOLZMPXGwWwn5MTkv9\r
  65         7Zy92u8Uzi59kxcn/ueOx/ptW2Y9L394qXan+afM2XzH7zGzKU+4euPWnSMLj77IWyHK6uFw\r
  66         7GVpUP3Dh+++v/vmKn7wa97lt3GRO63W7NV/c9NXW2/+LdXLRceM5H43cE1c3cFWeVZmtidz\r
  67         bKCDYPxsLSWW4oxEQy3mouJEAGfMYYIWAwAA\r
  68 Cc: notmuch@notmuchmail.org\r
  69 X-BeenThere: notmuch@notmuchmail.org\r
  70 X-Mailman-Version: 2.1.13\r
  71 Precedence: list\r
  72 List-Id: "Use and development of the notmuch mail system."\r
  73         <notmuch.notmuchmail.org>\r
  74 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  75         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  76 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  77 List-Post: <mailto:notmuch@notmuchmail.org>\r
  78 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  79 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  80         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  81 X-List-Received-Date: Thu, 30 Jan 2014 22:02:47 -0000\r
  82 \r
  83 Quoth Jani Nikula on Jan 25 at  5:38 pm:\r
  84 > On Sat, 25 Jan 2014, Jani Nikula <jani@nikula.org> wrote:\r
  85 > > Perhaps we need to have two prefixes, one of which is the literal\r
  86 > > filesystem folder and another which hides the implementation details,\r
  87 > > like I mentioned in my mail to Peter [1]. But consider this: my proposed\r
  88 > > implementation does cover *all* use cases.\r
  89 > \r
  90 > Here's a thought. With boolean prefix folder:, we can devise a scheme\r
  91 > where the folder: query defines what is to be matched.\r
  92 > \r
  93 > For example:\r
  94 > \r
  95 > folder:foo    match files in foo, foo/new, and foo/cur.\r
  96 > folder:foo/   match all files in all subdirectories under foo (this\r
  97 >               would handle Tomi's use case), including foo/new and foo/cur.\r
  98 > folder:foo/.  match in foo only, and specifically not in foo/cur or foo/new.\r
  99 > folder:foo/new  match in foo/new, and specifically not in foo/cur (this\r
 100 >               allows distinguishing between messages in cur and new).\r
 101 > folder:/      match everything.\r
 102 > folder:/.     match in top level maildir only.\r
 103 > folder:""     match in top level maildir, including cur/new.\r
 104 > \r
 105 > This requires indexing all the path components with suitable\r
 106 > suffixes. For example, a file "foo/new/baz" would get terms "/", "foo",\r
 107 > "foo/", "foo/new", and "foo/new/.". A file foo/bar would get terms "/",\r
 108 > "foo", "foo/", and "foo/.".\r
 109 > \r
 110 > It's obviously a concern this increases the database size; not sure how\r
 111 > it would compare with the current stemmed probabilistic prefix.\r
 112 > \r
 113 > Opinions on this? This would really cover all use cases, and address\r
 114 > Austin's interface and backward compatibility concerns.\r
 115 \r
 116 I like this idea in general, though I agree with others that the\r
 117 specific syntax seems a little wanting.  The concept of adding several\r
 118 boolean terms seems powerful, and I would be surprised if the extra\r
 119 terms had any substantive effect on database size.\r
 120 \r
 121 However, it seems like this is overloading one prefix for two\r
 122 meanings.  And I think that's because people want two similar but\r
 123 distinct things.  Several of us want a simple, natural Maildir-aware\r
 124 folder search (the Maildir folder of "a/b/cur/x:2," is "a/b").  Others\r
 125 want file system search.  It's easy to conflate these because Maildir\r
 126 represents folders as directory paths, but maybe they need to be\r
 127 treated as distinct things.\r
 128 \r
 129 What if we introduce two prefixes, say folder: and path: (maybe dir:?)\r
 130 to address both use cases, each as naturally as possible?  Both would\r
 131 be boolean prefixes because of the limitations of probabilistic\r
 132 prefixes, but we could take advantage of Jani's idea of generating\r
 133 several boolean terms.\r
 134 \r
 135 folder: could work the way I suggested (simply the path to the file,\r
 136 with {cur,new} stripped off).  path: would support file system search\r
 137 uses.  These seem more varied, but I think fall into exact match and\r
 138 recursive match.  Since I don't have this use case, I can't have any\r
 139 strong opinions about syntax, but I'll throw out an idea: many shells\r
 140 support "**" for recursive path matching and people are already quite\r
 141 familiar with glob patterns for paths, so why not simply adopt this?\r
 142 In other words, when adding the path "a/b/cur/x:2," add path: terms\r
 143 "a/b/cur" and "a/b/**" and "a/**" and "**".\r
 144 \r
 145 > BR,\r
 146 > Jani.\r