Xapian locking errors with custom query parser
Austin Clements
amdragon at mit.edu
Mon Mar 21 00:51:33 PDT 2011
On Fri, Mar 11, 2011 at 3:58 AM, Michal Sojka <sojkam1 at fel.cvut.cz> wrote:
> On Fri, 11 Mar 2011, Carl Worth wrote:
>> I've finally had a chance to start looking at this.
>
> [...]
>
>> 1. For "new" search features (ADJ,NEAR,etc.) I do not have a strong
>> interest in compatibility with Xapian.
>>
>> I was very careful when I wrote the documentation for the notmuch
>> search syntax to only document features that I had used and tested,
>> and that I was sure I wanted. (I was already thinking forward to
>> perhaps writing a custom query parser at some point.)
>>
>> So you should really use our existing documentation as the
>> guide. Please implement and test what it says.
>>
>> Beyond that, if you want to add additional features not mentioned in
>> our documentation, then feel free to, and there's no good reason not
>> to be Xapian compatible. But I also don't think there's a strong
>> reason that we have to be compatible.
>
> Additionally, I'd suggest to support value range queries for dates with
> ".." syntax. Besides that some users may relay on this syntax, I use
> date searches a lot and with custom query parser I have to type
> "after:yesterday", which is unnecessarily long. I wish that
> "yesterday..", which is much easier to type, would do the same.
> Similarly, "mon..wed" would be easier to type than "after:mon
> before:wed". What do you think?
Personally, I just don't understand the .. range syntax, which is why
I left it out (also, I was following the example in the TODO file).
It's completely inconsistent with the rest of the query syntax and
makes no indication of what it's a range over (what if you had other
ordinal values to search over? what if you could search by the
received date or the sent date?).
What about something like "date:mon..wed"? That's consistent with the
query syntax (the range part becomes part of the date syntax, not part
of the top-level query syntax), it indicates the domain of the search
term in a clean and extensible way, and it's succinct.
More information about the notmuch
mailing list