From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id A829C431FBD for ; Tue, 4 Feb 2014 12:14:35 -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 nEw181Iz-KGG for ; Tue, 4 Feb 2014 12:14:29 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id 41D51431FBC for ; Tue, 4 Feb 2014 12:14:29 -0800 (PST) X-AuditID: 12074423-f79726d000000cc9-1a-52f14a240fc6 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-6.mit.edu (Symantec Messaging Gateway) with SMTP id 0B.03.03273.42A41F25; Tue, 4 Feb 2014 15:14:28 -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 s14KERLH013200; Tue, 4 Feb 2014 15:14:27 -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 s14KEO2V021229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 4 Feb 2014 15:14:26 -0500 Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.80) (envelope-from ) id 1WAmO0-00017W-IH; Tue, 04 Feb 2014 15:14:24 -0500 Date: Tue, 4 Feb 2014 15:14:23 -0500 From: Austin Clements To: Rob Browning Subject: Re: [PATCH 0/5] lib: make folder: prefix literal Message-ID: <20140204201423.GP4375@mit.edu> References: <87y525m649.fsf@awakening.csail.mit.edu> <87r47wfltb.fsf@nikula.org> <87iot8f4vg.fsf@nikula.org> <20140130220234.GI4375@mit.edu> <871tzovu0c.fsf@trouble.defaultvalue.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871tzovu0c.fsf@trouble.defaultvalue.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRYrdT0VXx+hhksOMzt0XTdGeL6zdnMlv0 91xhcWD2WL/3M5vHrfuv2T2erbrFHMAcxWWTkpqTWZZapG+XwJXRPSOt4DZfxam/PYwNjHe5 uxg5OSQETCRO7rnLBmGLSVy4tx7I5uIQEpjNJHF833N2CGcDo0T/gRNQmVNMEmcvrWKFcJYw SkzYcIYZpJ9FQEWifeo6VhCbTUBDYtv+5YwgtoiAusTTTffAdjALWEk0bPkAFhcWsJSYemcK E4jNK6AtMW/uJKh1zxkl5m/rhUoISpyc+YQFollL4sa/l0BxDiBbWmL5Pw6QMKeAmcSGxTvA ZooC3TDl5Da2CYxCs5B0z0LSPQuhewEj8ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdM73czBK9 1JTSTYzgUHdR3sH456DSIUYBDkYlHt4O0Y9BQqyJZcWVuYcYJTmYlER5rzgAhfiS8lMqMxKL M+KLSnNSiw8xSnAwK4nwmn3+ECTEm5JYWZValA+TkuZgURLnTZzxJkhIID2xJDU7NbUgtQgm K8PBoSTBK+4JNFSwKDU9tSItM6cEIc3EwQkynAdouCpIDW9xQWJucWY6RP4Uo6KUOG+0B1BC ACSRUZoH1wtLRa8YxYFeEeblB2nnAaYxuO5XQIOZgAavc30PMrgkESEl1cAo6xij/f7Q38+M H3XFvRe8Uzc7cME8e28Iy9WM5xk5ihN4DfIqknXeJ61nFC98IqumlnH26cMNfWtuvc/YH3B+ F/t2l0Lel+e6dW0/6oSKbDpzKPzfOX+eQ1JCu3bnTXPw+fPgTXOY8qQMDjPeN1yL+v/mOrFc mVF0dqeVv7jY6sfZbuK1Uz4psRRnJBpqMRcVJwIAK2Fo+yADAAA= 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:14:35 -0000 Quoth Rob Browning on Jan 31 at 1:19 pm: > Austin Clements writes: > > > folder: could work the way I suggested (simply the path to the file, > > with {cur,new} stripped off). > > Hmm, so would notmuch try to guess whether or not it's dealing with a > maildir++ tree, and if so convert folder:foo to a search of .foo, and/or > folder:foo/bar to .foo.bar? Or would the user just need to know to say > folder:.foo and folder:.foo.bar? My opinion on this has changed over time, but I don't think we should try to interpret Maildir++ trees specially. That is, the user would have to say folder:.foo.bar if they're using Maildir++. The "." seems as good as a "/" for a separator, so we might as well not translate it. The leading "." is annoying, but *shrug* so is Maildir++. > And if we're only planning special treatment for for maildir-like > stores, then I wonder if the term should just be maildir:? The simple algorithm of taking the relative path and stripping {new,cur} (if present) does a good job of supporting both Maildir and non-Maildir stores (while balancing this support with simplicity, predictability, and usability). > Though folder: would make more sense if the long-term goal was to have a > "DTRT" term. But in that case, I wonder if it might eventually be > expected to support mixed trees, i.e. say a tree containing maildir++ > and mh subdirs, and if so, how that should be handled. The simple {new,cur}-stripping algorithm already does fairly well at this. Worrying more about mixed Maildir++ and MH stores seems unnecessary to me unless someone demonstrates and actual need. > > many shells support "**" for recursive path matching and people are > > already quite familiar with glob patterns for paths, so why not simply > > adopt this? > > rsync too. Ah, sure enough. Even better!