1 Return-Path: <amdragon@mit.edu>
\r
2 X-Original-To: notmuch@notmuchmail.org
\r
3 Delivered-To: notmuch@notmuchmail.org
\r
4 Received: from localhost (localhost [127.0.0.1])
\r
5 by olra.theworths.org (Postfix) with ESMTP id A829C431FBD
\r
6 for <notmuch@notmuchmail.org>; Tue, 4 Feb 2014 12:14:35 -0800 (PST)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5
\r
12 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled
\r
13 Received: from olra.theworths.org ([127.0.0.1])
\r
14 by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)
\r
15 with ESMTP id nEw181Iz-KGG for <notmuch@notmuchmail.org>;
\r
16 Tue, 4 Feb 2014 12:14:29 -0800 (PST)
\r
17 Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu
\r
19 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
\r
20 (No client certificate requested)
\r
21 by olra.theworths.org (Postfix) with ESMTPS id 41D51431FBC
\r
22 for <notmuch@notmuchmail.org>; Tue, 4 Feb 2014 12:14:29 -0800 (PST)
\r
23 X-AuditID: 12074423-f79726d000000cc9-1a-52f14a240fc6
\r
24 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36])
\r
25 (using TLS with cipher AES256-SHA (256/256 bits))
\r
26 (Client did not present a certificate)
\r
27 by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP
\r
28 id 0B.03.03273.42A41F25; Tue, 4 Feb 2014 15:14:28 -0500 (EST)
\r
29 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
\r
30 by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s14KERLH013200;
\r
31 Tue, 4 Feb 2014 15:14:27 -0500
\r
32 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91])
\r
33 (authenticated bits=0)
\r
34 (User authenticated as amdragon@ATHENA.MIT.EDU)
\r
35 by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s14KEO2V021229
\r
36 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);
\r
37 Tue, 4 Feb 2014 15:14:26 -0500
\r
38 Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.80)
\r
39 (envelope-from <amdragon@mit.edu>)
\r
40 id 1WAmO0-00017W-IH; Tue, 04 Feb 2014 15:14:24 -0500
\r
41 Date: Tue, 4 Feb 2014 15:14:23 -0500
\r
42 From: Austin Clements <amdragon@MIT.EDU>
\r
43 To: Rob Browning <rlb@defaultvalue.org>
\r
44 Subject: Re: [PATCH 0/5] lib: make folder: prefix literal
\r
45 Message-ID: <20140204201423.GP4375@mit.edu>
\r
46 References: <cover.1389304779.git.jani@nikula.org>
\r
47 <87y525m649.fsf@awakening.csail.mit.edu>
\r
48 <87r47wfltb.fsf@nikula.org> <87iot8f4vg.fsf@nikula.org>
\r
49 <20140130220234.GI4375@mit.edu>
\r
50 <871tzovu0c.fsf@trouble.defaultvalue.org>
\r
52 Content-Type: text/plain; charset=us-ascii
\r
53 Content-Disposition: inline
\r
54 In-Reply-To: <871tzovu0c.fsf@trouble.defaultvalue.org>
\r
55 User-Agent: Mutt/1.5.21 (2010-09-15)
\r
56 X-Brightmail-Tracker:
\r
57 H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRYrdT0VXx+hhksOMzt0XTdGeL6zdnMlv0
\r
58 91xhcWD2WL/3M5vHrfuv2T2erbrFHMAcxWWTkpqTWZZapG+XwJXRPSOt4DZfxam/PYwNjHe5
\r
59 uxg5OSQETCRO7rnLBmGLSVy4tx7I5uIQEpjNJHF833N2CGcDo0T/gRNQmVNMEmcvrWKFcJYw
\r
60 SkzYcIYZpJ9FQEWifeo6VhCbTUBDYtv+5YwgtoiAusTTTffAdjALWEk0bPkAFhcWsJSYemcK
\r
61 E4jNK6AtMW/uJKh1zxkl5m/rhUoISpyc+YQFollL4sa/l0BxDiBbWmL5Pw6QMKeAmcSGxTvA
\r
62 ZooC3TDl5Da2CYxCs5B0z0LSPQuhewEj8ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdM73czBK9
\r
63 1JTSTYzgUHdR3sH456DSIUYBDkYlHt4O0Y9BQqyJZcWVuYcYJTmYlER5rzgAhfiS8lMqMxKL
\r
64 M+KLSnNSiw8xSnAwK4nwmn3+ECTEm5JYWZValA+TkuZgURLnTZzxJkhIID2xJDU7NbUgtQgm
\r
65 K8PBoSTBK+4JNFSwKDU9tSItM6cEIc3EwQkynAdouCpIDW9xQWJucWY6RP4Uo6KUOG+0B1BC
\r
66 ACSRUZoH1wtLRa8YxYFeEeblB2nnAaYxuO5XQIOZgAavc30PMrgkESEl1cAo6xij/f7Q38+M
\r
67 H3XFvRe8Uzc7cME8e28Iy9WM5xk5ihN4DfIqknXeJ61nFC98IqumlnH26cMNfWtuvc/YH3B+
\r
68 F/t2l0Lel+e6dW0/6oSKbDpzKPzfOX+eQ1JCu3bnTXPw+fPgTXOY8qQMDjPeN1yL+v/mOrFc
\r
69 mVF0dqeVv7jY6sfZbuK1Uz4psRRnJBpqMRcVJwIAK2Fo+yADAAA=
\r
70 Cc: notmuch@notmuchmail.org
\r
71 X-BeenThere: notmuch@notmuchmail.org
\r
72 X-Mailman-Version: 2.1.13
\r
74 List-Id: "Use and development of the notmuch mail system."
\r
75 <notmuch.notmuchmail.org>
\r
76 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
77 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
78 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
79 List-Post: <mailto:notmuch@notmuchmail.org>
\r
80 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
81 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
82 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
83 X-List-Received-Date: Tue, 04 Feb 2014 20:14:35 -0000
\r
85 Quoth Rob Browning on Jan 31 at 1:19 pm:
\r
86 > Austin Clements <amdragon@MIT.EDU> writes:
\r
88 > > folder: could work the way I suggested (simply the path to the file,
\r
89 > > with {cur,new} stripped off).
\r
91 > Hmm, so would notmuch try to guess whether or not it's dealing with a
\r
92 > maildir++ tree, and if so convert folder:foo to a search of .foo, and/or
\r
93 > folder:foo/bar to .foo.bar? Or would the user just need to know to say
\r
94 > folder:.foo and folder:.foo.bar?
\r
96 My opinion on this has changed over time, but I don't think we should
\r
97 try to interpret Maildir++ trees specially. That is, the user would
\r
98 have to say folder:.foo.bar if they're using Maildir++. The "." seems
\r
99 as good as a "/" for a separator, so we might as well not translate
\r
100 it. The leading "." is annoying, but *shrug* so is Maildir++.
\r
102 > And if we're only planning special treatment for for maildir-like
\r
103 > stores, then I wonder if the term should just be maildir:?
\r
105 The simple algorithm of taking the relative path and stripping
\r
106 {new,cur} (if present) does a good job of supporting both Maildir and
\r
107 non-Maildir stores (while balancing this support with simplicity,
\r
108 predictability, and usability).
\r
110 > Though folder: would make more sense if the long-term goal was to have a
\r
111 > "DTRT" term. But in that case, I wonder if it might eventually be
\r
112 > expected to support mixed trees, i.e. say a tree containing maildir++
\r
113 > and mh subdirs, and if so, how that should be handled.
\r
115 The simple {new,cur}-stripping algorithm already does fairly well at
\r
116 this. Worrying more about mixed Maildir++ and MH stores seems
\r
117 unnecessary to me unless someone demonstrates and actual need.
\r
119 > > many shells support "**" for recursive path matching and people are
\r
120 > > already quite familiar with glob patterns for paths, so why not simply
\r
125 Ah, sure enough. Even better!
\r