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

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