Re: [PATCH 0/5] lib: make folder: prefix literal

Subject: Re: [PATCH 0/5] lib: make folder: prefix literal

Date: Thu, 30 Jan 2014 07:34:24 +0100

To: Carl Worth, Austin Clements

Cc: notmuch@notmuchmail.org

From: Jani Nikula


On Wed, 29 Jan 2014, Carl Worth <cworth@cworth.org> wrote:
> Austin Clements <aclements@csail.mit.edu> writes:
>> I think you're assuming we have much more control over this than we
>> do.
>
> To be fair, I only started discussing my proposal for '^' and '$' in
> response to Jani's proposal with special semantics for trailing '/' and
> "/.".

I only chose those to avoid any collisions with actual file names,
without much further thought. I'm not a fan of rsync's trailing '/'
semantics either. The main point was to demonstrate that if folder: were
a boolean prefix, it would be possible to index folder terms in a way
that would address the issues with the current folder: prefix.

I don't have good counter-proposals now, but an *example* is having
"sub-prefixes" like "folder:recursive::foo" or "folder:maildir::bar",
where the former would match anything under foo and the latter would
match anything in bar/new and bar/cur. These "recursive::" and
"maildir::" prefixes would be just part of the indexed boolean terms.

> Support for any of this magic syntax would require a custom query
> parser, yes.
>
> Austin, haven't you been proposing a custom query parser for ages? Where
> does that work stand now?

That is the unicorn... many of the query improvements I have in mind
depend on a custom query parser. So I'd like to have that. And a
pony. But in the mean time, I'm left wondering whether I should pursue
folder: as a boolean prefix, or try to figure out if there are
improvements to be made as a probabilistic prefix, or just put this work
on hold. With the db upgrade and upgrade tests, it's not exactly a
trivial amount of work.

BR,
Jani.

Thread: