--- /dev/null
+Return-Path: <amdragon@mit.edu>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id 5FA8F431FB6\r
+ for <notmuch@notmuchmail.org>; Thu, 30 Jan 2014 14:02:47 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.7\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
+ tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id gykcxSB7ztQl for <notmuch@notmuchmail.org>;\r
+ Thu, 30 Jan 2014 14:02:41 -0800 (PST)\r
+Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu\r
+ [18.7.68.37])\r
+ (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
+ (No client certificate requested)\r
+ by olra.theworths.org (Postfix) with ESMTPS id 66F21431FBD\r
+ for <notmuch@notmuchmail.org>; Thu, 30 Jan 2014 14:02:41 -0800 (PST)\r
+X-AuditID: 12074425-f79906d000000cf9-1b-52eacc005076\r
+Received: from mailhub-auth-1.mit.edu ( [18.9.21.35])\r
+ (using TLS with cipher AES256-SHA (256/256 bits))\r
+ (Client did not present a certificate)\r
+ by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP\r
+ id 9A.BD.03321.00CCAE25; Thu, 30 Jan 2014 17:02:40 -0500 (EST)\r
+Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])\r
+ by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s0UM2cxg030481; \r
+ Thu, 30 Jan 2014 17:02:39 -0500\r
+Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91])\r
+ (authenticated bits=0)\r
+ (User authenticated as amdragon@ATHENA.MIT.EDU)\r
+ by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s0UM2ZtW008034\r
+ (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);\r
+ Thu, 30 Jan 2014 17:02:37 -0500\r
+Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.80)\r
+ (envelope-from <amdragon@mit.edu>)\r
+ id 1W8zgx-0007d3-7K; Thu, 30 Jan 2014 17:02:35 -0500\r
+Date: Thu, 30 Jan 2014 17:02:34 -0500\r
+From: Austin Clements <amdragon@MIT.EDU>\r
+To: Jani Nikula <jani@nikula.org>\r
+Subject: Re: [PATCH 0/5] lib: make folder: prefix literal\r
+Message-ID: <20140130220234.GI4375@mit.edu>\r
+References: <cover.1389304779.git.jani@nikula.org>\r
+ <87y525m649.fsf@awakening.csail.mit.edu>\r
+ <87r47wfltb.fsf@nikula.org> <87iot8f4vg.fsf@nikula.org>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+Content-Disposition: inline\r
+In-Reply-To: <87iot8f4vg.fsf@nikula.org>\r
+User-Agent: Mutt/1.5.21 (2010-09-15)\r
+X-Brightmail-Tracker:\r
+ H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IR4hRV1mU48yrIYN9eCYum6c4W12/OZHZg\r
+ 8rh1/zW7x7NVt5gDmKK4bFJSczLLUov07RK4Mh7t3M1WsFSyYvpb3wbGbSJdjJwcEgImEid/\r
+ T2eHsMUkLtxbz9bFyMUhJDCbSeLihzcsEM5GRolF77awQjinmSRm/9rCDuEsYZRY23eNCaSf\r
+ RUBVYlnbHVYQm01AQ2Lb/uWMILaIgKLE5pP7wWxmAWmJb7+bweqFBSwlpt6ZAmbzCmhLLLw5\r
+ H2roTEaJGR0XmCESghInZz5hgWjWkrjx7yVQAwfYoOX/OEDCnEC7Vu1vBysXFVCRmHJyG9sE\r
+ RqFZSLpnIemehdC9gJF5FaNsSm6Vbm5iZk5xarJucXJiXl5qka6FXm5miV5qSukmRlBYs7uo\r
+ 7mCccEjpEKMAB6MSD++MtFdBQqyJZcWVuYcYJTmYlER53+0CCvEl5adUZiQWZ8QXleakFh9i\r
+ lOBgVhLhfd8PlONNSaysSi3Kh0lJc7AoifPe4rAPEhJITyxJzU5NLUgtgsnKcHAoSfB+OQXU\r
+ KFiUmp5akZaZU4KQZuLgBBnOAzSc6zTI8OKCxNzizHSI/ClGRSlx3h0gzQIgiYzSPLheWNp5\r
+ xSgO9Iow7z+QKh5gyoLrfgU0mAlosFY52OCSRISUVANjoNWDfbO5DLtOLZMPXGwWwn5MTkv9\r
+ 7Zy92u8Uzi59kxcn/ueOx/ptW2Y9L394qXan+afM2XzH7zGzKU+4euPWnSMLj77IWyHK6uFw\r
+ 7GVpUP3Dh+++v/vmKn7wa97lt3GRO63W7NV/c9NXW2/+LdXLRceM5H43cE1c3cFWeVZmtidz\r
+ bKCDYPxsLSWW4oxEQy3mouJEAGfMYYIWAwAA\r
+Cc: notmuch@notmuchmail.org\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Thu, 30 Jan 2014 22:02:47 -0000\r
+\r
+Quoth Jani Nikula on Jan 25 at 5:38 pm:\r
+> On Sat, 25 Jan 2014, Jani Nikula <jani@nikula.org> wrote:\r
+> > Perhaps we need to have two prefixes, one of which is the literal\r
+> > filesystem folder and another which hides the implementation details,\r
+> > like I mentioned in my mail to Peter [1]. But consider this: my proposed\r
+> > implementation does cover *all* use cases.\r
+> \r
+> Here's a thought. With boolean prefix folder:, we can devise a scheme\r
+> where the folder: query defines what is to be matched.\r
+> \r
+> For example:\r
+> \r
+> folder:foo match files in foo, foo/new, and foo/cur.\r
+> folder:foo/ match all files in all subdirectories under foo (this\r
+> would handle Tomi's use case), including foo/new and foo/cur.\r
+> folder:foo/. match in foo only, and specifically not in foo/cur or foo/new.\r
+> folder:foo/new match in foo/new, and specifically not in foo/cur (this\r
+> allows distinguishing between messages in cur and new).\r
+> folder:/ match everything.\r
+> folder:/. match in top level maildir only.\r
+> folder:"" match in top level maildir, including cur/new.\r
+> \r
+> This requires indexing all the path components with suitable\r
+> suffixes. For example, a file "foo/new/baz" would get terms "/", "foo",\r
+> "foo/", "foo/new", and "foo/new/.". A file foo/bar would get terms "/",\r
+> "foo", "foo/", and "foo/.".\r
+> \r
+> It's obviously a concern this increases the database size; not sure how\r
+> it would compare with the current stemmed probabilistic prefix.\r
+> \r
+> Opinions on this? This would really cover all use cases, and address\r
+> Austin's interface and backward compatibility concerns.\r
+\r
+I like this idea in general, though I agree with others that the\r
+specific syntax seems a little wanting. The concept of adding several\r
+boolean terms seems powerful, and I would be surprised if the extra\r
+terms had any substantive effect on database size.\r
+\r
+However, it seems like this is overloading one prefix for two\r
+meanings. And I think that's because people want two similar but\r
+distinct things. Several of us want a simple, natural Maildir-aware\r
+folder search (the Maildir folder of "a/b/cur/x:2," is "a/b"). Others\r
+want file system search. It's easy to conflate these because Maildir\r
+represents folders as directory paths, but maybe they need to be\r
+treated as distinct things.\r
+\r
+What if we introduce two prefixes, say folder: and path: (maybe dir:?)\r
+to address both use cases, each as naturally as possible? Both would\r
+be boolean prefixes because of the limitations of probabilistic\r
+prefixes, but we could take advantage of Jani's idea of generating\r
+several boolean terms.\r
+\r
+folder: could work the way I suggested (simply the path to the file,\r
+with {cur,new} stripped off). path: would support file system search\r
+uses. These seem more varied, but I think fall into exact match and\r
+recursive match. Since I don't have this use case, I can't have any\r
+strong opinions about syntax, but I'll throw out an idea: many shells\r
+support "**" for recursive path matching and people are already quite\r
+familiar with glob patterns for paths, so why not simply adopt this?\r
+In other words, when adding the path "a/b/cur/x:2," add path: terms\r
+"a/b/cur" and "a/b/**" and "a/**" and "**".\r
+\r
+> BR,\r
+> Jani.\r
projects / notmuch-archives.git / commitdiff