From: Austin Clements Date: Tue, 4 Feb 2014 20:02:50 +0000 (+1900) Subject: Re: [PATCH 0/5] lib: make folder: prefix literal X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=88841455ace891c4b3f895a2d53fe088453cbe90;p=notmuch-archives.git Re: [PATCH 0/5] lib: make folder: prefix literal --- diff --git a/6c/acd0e7a9da4484d8b9e7736a258e99463f814c b/6c/acd0e7a9da4484d8b9e7736a258e99463f814c new file mode 100644 index 000000000..365ced223 --- /dev/null +++ b/6c/acd0e7a9da4484d8b9e7736a258e99463f814c @@ -0,0 +1,185 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 85F71431FBD + for ; Tue, 4 Feb 2014 12:03:02 -0800 (PST) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: -0.7 +X-Spam-Level: +X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 + tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id kVDQK1MIWEbS for ; + Tue, 4 Feb 2014 12:02:57 -0800 (PST) +Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu + [18.7.68.36]) + (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id D255B431FBC + for ; Tue, 4 Feb 2014 12:02:56 -0800 (PST) +X-AuditID: 12074424-f79e26d000000c70-9c-52f1476fe34b +Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) + (using TLS with cipher AES256-SHA (256/256 bits)) + (Client did not present a certificate) + by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP + id C1.59.03184.F6741F25; Tue, 4 Feb 2014 15:02:55 -0500 (EST) +Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) + by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s14K2sQS010802; + Tue, 4 Feb 2014 15:02:55 -0500 +Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91]) + (authenticated bits=0) + (User authenticated as amdragon@ATHENA.MIT.EDU) + by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s14K2pMJ011859 + (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); + Tue, 4 Feb 2014 15:02:53 -0500 +Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.80) + (envelope-from ) + id 1WAmCo-000142-PD; Tue, 04 Feb 2014 15:02:50 -0500 +Date: Tue, 4 Feb 2014 15:02:50 -0500 +From: Austin Clements +To: Jani Nikula +Subject: Re: [PATCH 0/5] lib: make folder: prefix literal +Message-ID: <20140204200249.GO4375@mit.edu> +References: + <87y525m649.fsf@awakening.csail.mit.edu> + <87r47wfltb.fsf@nikula.org> <87iot8f4vg.fsf@nikula.org> + <20140130220234.GI4375@mit.edu> <87fvo2yjc4.fsf@nikula.org> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: <87fvo2yjc4.fsf@nikula.org> +User-Agent: Mutt/1.5.21 (2010-09-15) +X-Brightmail-Tracker: + H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IRYrdT0c13/xhk0LbEwKJpurPF9ZszmR2Y + PG7df83u8WzVLeYApigum5TUnMyy1CJ9uwSujGU7z7EVvJSp2PDhEFsD406xLkZODgkBE4nG + Y4cYIWwxiQv31rN1MXJxCAnMZpKY0LyDBcLZwCgxa0YXK4Rzikmic8p6VpAWIYEljBLTr+WC + 2CwCKhJ90zvA4mwCGhLb9i8HGysioCix+eR+MJtZQFri2+9mJhBbWMBSYuqdKWA2r4C2xPHf + t6BW32SU6L9+mAUiIShxcuYTFohmLYkb/14CNXCADVr+jwMkzAm068GmbWB7RYFumHJyG9sE + RqFZSLpnIemehdC9gJF5FaNsSm6Vbm5iZk5xarJucXJiXl5qka65Xm5miV5qSukmRnBYu6js + YGw+pHSIUYCDUYmHt0P0Y5AQa2JZcWXuIUZJDiYlUd4rDkAhvqT8lMqMxOKM+KLSnNTiQ4wS + HMxKIrxmnz8ECfGmJFZWpRblw6SkOViUxHkTZ7wJEhJITyxJzU5NLUgtgsnKcHAoSfC2uQEN + FSxKTU+tSMvMKUFIM3FwggznARoeAVLDW1yQmFucmQ6RP8WoKCXOawySEABJZJTmwfXC0s4r + RnGgV4R5K0GqeIApC677FdBgJqDB61zfgwwuSURISTUw5h3YYuDOtSxTd/USFePmYs7GgLT1 + F/dM0+J8w8Pd4ulyQ7pg2r8FTTrsd0OETeScJjGd1K9ZbL7V0VK1REZ7o2b+z3sact7vZiqk + GNQL8Gpn1OwUKpqrWP4q8dkFmdvfd9nqbXSo5nn74c7i+RX+c479TCs15/ONL5oQKvie5Xw2 + 1/rpi02UWIozEg21mIuKEwFgAnBJFgMAAA== +Cc: notmuch@notmuchmail.org +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Tue, 04 Feb 2014 20:03:02 -0000 + +Quoth Jani Nikula on Feb 01 at 4:54 pm: +> On Fri, 31 Jan 2014, Austin Clements wrote: +> > What if we introduce two prefixes, say folder: and path: (maybe dir:?) +> > to address both use cases, each as naturally as possible? Both would +> > be boolean prefixes because of the limitations of probabilistic +> > prefixes, but we could take advantage of Jani's idea of generating +> > several boolean terms. +> +> Agreed. On to details: +> +> > folder: could work the way I suggested (simply the path to the file, +> > with {cur,new} stripped off). +> +> What if the file is not in a folder named cur/new? I suggest indexing +> the folder as-is, if only for some backwards compatibility. + +Agreed. I believe this will also support MH, if I understand MH +correctly (does anyone actually use MH?) + +> What if there is not all of cur/new/tmp folders? I suggest ignoring +> that, and only look at the path to the file being indexed. This is +> simplest to implement, and it does not matter if the sibling directories +> come and go, and for this reason also unsurprising. + +That sounds good to me. + +> For top level cur/new, index the empty string "". + +Yes. + +> > path: would support file system search +> > uses. These seem more varied, but I think fall into exact match and +> > recursive match. Since I don't have this use case, I can't have any +> > strong opinions about syntax, but I'll throw out an idea: many shells +> > support "**" for recursive path matching and people are already quite +> > familiar with glob patterns for paths, so why not simply adopt this? +> > In other words, when adding the path "a/b/cur/x:2," add path: terms +> > "a/b/cur" and "a/b/**" and "a/**" and "**". +> +> Since folder: would cover the cur/new cases, I suggest the non-recursive +> variant of path: prefix is the exact filesystem folder name as-is (with +> the top level being the empty string ""). I presume this is what you +> meant too. + +Yes. I suppose I didn't actually say it, but that's what I was +thinking. + +> I kind of like the "/**" suffix for recursive, but there's two small +> wrinkles: 1) it needs quoting on the command line (unlike my original +> suggestion of just "/" suffix), and 2) what should the top level +> recursive search be? path:"**" or path:"/**" or path:"./**"? I guess the +> first one is most obvious? + +The shell quoting is annoying, but depending on the shell, it should +at least give an error (zsh) or Just Work (apparently bash and sh pass +the unexpanded glob through if it doesn't match anything?). + +> So here's what my original suggestions would become: +> +> >> Here's a thought. With boolean prefix folder:, we can devise a scheme +> >> where the folder: query defines what is to be matched. +> >> +> >> For example: +> >> +> >> folder:foo match files in foo, foo/new, and foo/cur. +> +> -> folder:foo +> +> >> folder:foo/ match all files in all subdirectories under foo (this +> >> would handle Tomi's use case), including foo/new and foo/cur. +> +> -> path:"foo/**" +> +> >> folder:foo/. match in foo only, and specifically not in foo/cur or foo/new. +> +> -> path:foo +> +> >> folder:foo/new match in foo/new, and specifically not in foo/cur (this +> >> allows distinguishing between messages in cur and new). +> +> -> path:foo/new +> +> >> folder:/ match everything. +> +> -> path:"**" +> +> >> folder:/. match in top level maildir only. +> +> -> path:"" +> +> >> folder:"" match in top level maildir, including cur/new. +> +> -> folder:"" +> +> +> I'd like these details to be ironed out and agreed on before I send the +> next version. + +This all looks good to me. + +> BR, +> Jani.