Re: [PATCH 0/5] lib: make folder: prefix literal
authorAustin Clements <amdragon@MIT.EDU>
Tue, 4 Feb 2014 20:02:50 +0000 (15:02 +1900)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 17:59:44 +0000 (09:59 -0800)
6c/acd0e7a9da4484d8b9e7736a258e99463f814c [new file with mode: 0644]

diff --git a/6c/acd0e7a9da4484d8b9e7736a258e99463f814c b/6c/acd0e7a9da4484d8b9e7736a258e99463f814c
new file mode 100644 (file)
index 0000000..365ced2
--- /dev/null
@@ -0,0 +1,185 @@
+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 85F71431FBD\r
+       for <notmuch@notmuchmail.org>; Tue,  4 Feb 2014 12:03:02 -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 kVDQK1MIWEbS for <notmuch@notmuchmail.org>;\r
+       Tue,  4 Feb 2014 12:02:57 -0800 (PST)\r
+Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu\r
+       [18.7.68.36])\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 D255B431FBC\r
+       for <notmuch@notmuchmail.org>; Tue,  4 Feb 2014 12:02:56 -0800 (PST)\r
+X-AuditID: 12074424-f79e26d000000c70-9c-52f1476fe34b\r
+Received: from mailhub-auth-2.mit.edu ( [18.7.62.36])\r
+       (using TLS with cipher AES256-SHA (256/256 bits))\r
+       (Client did not present a certificate)\r
+       by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP\r
+       id C1.59.03184.F6741F25; Tue,  4 Feb 2014 15:02:55 -0500 (EST)\r
+Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])\r
+       by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s14K2sQS010802; \r
+       Tue, 4 Feb 2014 15:02:55 -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 s14K2pMJ011859\r
+       (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);\r
+       Tue, 4 Feb 2014 15:02:53 -0500\r
+Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.80)\r
+       (envelope-from <amdragon@mit.edu>)\r
+       id 1WAmCo-000142-PD; Tue, 04 Feb 2014 15:02:50 -0500\r
+Date: Tue, 4 Feb 2014 15:02:50 -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: <20140204200249.GO4375@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
+       <20140130220234.GI4375@mit.edu> <87fvo2yjc4.fsf@nikula.org>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+Content-Disposition: inline\r
+In-Reply-To: <87fvo2yjc4.fsf@nikula.org>\r
+User-Agent: Mutt/1.5.21 (2010-09-15)\r
+X-Brightmail-Tracker:\r
+ H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IRYrdT0c13/xhk0LbEwKJpurPF9ZszmR2Y\r
+       PG7df83u8WzVLeYApigum5TUnMyy1CJ9uwSujGU7z7EVvJSp2PDhEFsD406xLkZODgkBE4nG\r
+       Y4cYIWwxiQv31rN1MXJxCAnMZpKY0LyDBcLZwCgxa0YXK4Rzikmic8p6VpAWIYEljBLTr+WC\r
+       2CwCKhJ90zvA4mwCGhLb9i8HGysioCix+eR+MJtZQFri2+9mJhBbWMBSYuqdKWA2r4C2xPHf\r
+       t6BW32SU6L9+mAUiIShxcuYTFohmLYkb/14CNXCADVr+jwMkzAm068GmbWB7RYFumHJyG9sE\r
+       RqFZSLpnIemehdC9gJF5FaNsSm6Vbm5iZk5xarJucXJiXl5qka65Xm5miV5qSukmRnBYu6js\r
+       YGw+pHSIUYCDUYmHt0P0Y5AQa2JZcWXuIUZJDiYlUd4rDkAhvqT8lMqMxOKM+KLSnNTiQ4wS\r
+       HMxKIrxmnz8ECfGmJFZWpRblw6SkOViUxHkTZ7wJEhJITyxJzU5NLUgtgsnKcHAoSfC2uQEN\r
+       FSxKTU+tSMvMKUFIM3FwggznARoeAVLDW1yQmFucmQ6RP8WoKCXOawySEABJZJTmwfXC0s4r\r
+       RnGgV4R5K0GqeIApC677FdBgJqDB61zfgwwuSURISTUw5h3YYuDOtSxTd/USFePmYs7GgLT1\r
+       F/dM0+J8w8Pd4ulyQ7pg2r8FTTrsd0OETeScJjGd1K9ZbL7V0VK1REZ7o2b+z3sact7vZiqk\r
+       GNQL8Gpn1OwUKpqrWP4q8dkFmdvfd9nqbXSo5nn74c7i+RX+c479TCs15/ONL5oQKvie5Xw2\r
+       1/rpi02UWIozEg21mIuKEwFgAnBJFgMAAA==\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: Tue, 04 Feb 2014 20:03:02 -0000\r
+\r
+Quoth Jani Nikula on Feb 01 at  4:54 pm:\r
+> On Fri, 31 Jan 2014, Austin Clements <amdragon@MIT.EDU> wrote:\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
+> Agreed. On to details:\r
+> \r
+> > folder: could work the way I suggested (simply the path to the file,\r
+> > with {cur,new} stripped off).\r
+> \r
+> What if the file is not in a folder named cur/new? I suggest indexing\r
+> the folder as-is, if only for some backwards compatibility.\r
+\r
+Agreed.  I believe this will also support MH, if I understand MH\r
+correctly (does anyone actually use MH?)\r
+\r
+> What if there is not all of cur/new/tmp folders? I suggest ignoring\r
+> that, and only look at the path to the file being indexed. This is\r
+> simplest to implement, and it does not matter if the sibling directories\r
+> come and go, and for this reason also unsurprising.\r
+\r
+That sounds good to me.\r
+\r
+> For top level cur/new, index the empty string "".\r
+\r
+Yes.\r
+\r
+> > 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
+> Since folder: would cover the cur/new cases, I suggest the non-recursive\r
+> variant of path: prefix is the exact filesystem folder name as-is (with\r
+> the top level being the empty string ""). I presume this is what you\r
+> meant too.\r
+\r
+Yes.  I suppose I didn't actually say it, but that's what I was\r
+thinking.\r
+\r
+> I kind of like the "/**" suffix for recursive, but there's two small\r
+> wrinkles: 1) it needs quoting on the command line (unlike my original\r
+> suggestion of just "/" suffix), and 2) what should the top level\r
+> recursive search be? path:"**" or path:"/**" or path:"./**"? I guess the\r
+> first one is most obvious?\r
+\r
+The shell quoting is annoying, but depending on the shell, it should\r
+at least give an error (zsh) or Just Work (apparently bash and sh pass\r
+the unexpanded glob through if it doesn't match anything?).\r
+\r
+> So here's what my original suggestions would become:\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
+> \r
+> -> folder:foo\r
+> \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
+> \r
+> -> path:"foo/**"\r
+> \r
+> >> folder:foo/.      match in foo only, and specifically not in foo/cur or foo/new.\r
+> \r
+> -> path:foo\r
+> \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
+> \r
+> -> path:foo/new\r
+> \r
+> >> folder:/  match everything.\r
+> \r
+> -> path:"**"\r
+> \r
+> >> folder:/. match in top level maildir only.\r
+> \r
+> -> path:""\r
+> \r
+> >> folder:"" match in top level maildir, including cur/new.\r
+> \r
+> -> folder:""\r
+> \r
+> \r
+> I'd like these details to be ironed out and agreed on before I send the\r
+> next version.\r
+\r
+This all looks good to me.\r
+\r
+> BR,\r
+> Jani.\r