From e667652063243a50ff268cbb5aee2636dfd0b421 Mon Sep 17 00:00:00 2001 From: Austin Clements Date: Wed, 5 Feb 2014 15:14:23 +1900 Subject: [PATCH] Re: [PATCH 0/5] lib: make folder: prefix literal --- 22/e6250796cd03c7b7802b778997828c1057cd9f | 125 ++++++++++++++++++++++ 1 file changed, 125 insertions(+) create mode 100644 22/e6250796cd03c7b7802b778997828c1057cd9f diff --git a/22/e6250796cd03c7b7802b778997828c1057cd9f b/22/e6250796cd03c7b7802b778997828c1057cd9f new file mode 100644 index 000000000..fba7bf1f5 --- /dev/null +++ b/22/e6250796cd03c7b7802b778997828c1057cd9f @@ -0,0 +1,125 @@ +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 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! -- 2.26.2