From: Mark Walters <markwalters1009@gmail.com>
To: David Mazieres expires 2014-08-01 PDT
	<mazieres-kdhm6yewp4dq87x4tf5ix7eyxw@temporary-address.scs.stanford.edu>,
	Jani Nikula <jani@nikula.org>
Subject: Re: folder and path completely broken in HEAD?
In-Reply-To: <87iopmonzn.fsf@ta.scs.stanford.edu>
References: <87oazfo3w2.fsf@ta.scs.stanford.edu> <87zjiz8hft.fsf@qmul.ac.uk>
	<87iopmonzn.fsf@ta.scs.stanford.edu>
User-Agent: Notmuch/0.15.2+615~g78e3a93 (http://notmuchmail.org) Emacs/23.4.1
	(x86_64-pc-linux-gnu)
Date: Sat, 03 May 2014 19:57:15 +0100
Message-ID: <87ppju4rn8.fsf@qmul.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: notmuch@notmuchmail.org
Precedence: list


Hi

On Sat, 03 May 2014, dm-list-email-notmuch@scs.stanford.edu wrote:
> Mark Walters <markwalters1009@gmail.com> writes:
>
>>> All the way back.  Now you are saying there will be no convenient way to
>>> match just the "mail.class" part without the year?  How very
>>> distressing.  Ugh.
>>
>> Hi
>>
>> I am not quite sure what you are meaning by hierarchically group
>> messages. Searching for path:dir/foo/bar/** should give all messages in
>> all directories beneath dir/foo/bar. 
>
> The problem is that the maildir++ spec disallows such pathnames.  If I
> need compatibility with maildir++ (for instance for an imap server), at
> least on a per-year basis, then my maildirs have to have names like:
>
>    2013/.foo.foo
>    2013/.foo.bar
>    2013/.foo.baz
>    2014/.foo.foo
>    2014/.foo.bar
>    2014/.foo.baz
>
> So if I want a way to aggregate all my foo mail in a single search,
> right now I just ask for folder:foo.  Will there be any equivalent in
> the new notmuch?

I agree with Jani that for 0.18 this won't be possible. However, there
is probably no urgent reason to upgrade (given you know it will cause
you some problems) so the question is can we add some functionality to
cover this use case. Given the way we do the folder matching I think it
unlikely we would want to add globbing/wildcards to the start of a path
(*).

However, we might be able to support maildir++ as its own prefix. If you
could so searches of the form maildir++:.foo.bar.** which would match
the maildir .foo.bar and all submaildirs++ (eg .foo.bar.a.b etc) would
that be sufficient?

This wouldn't deal with 2013/.foo.bar but would allow .foo.bar.2013

Would this be enough help to make it worth considering?

Best wishes

Mark

(*) if we get a custom parser then it may all be manageable.