Re: Xapian locking errors with custom query parser

diff --git a/fd/12c218854821675af324c3b3e243ec5a196569 b/fd/12c218854821675af324c3b3e243ec5a196569
new file mode 100644 (file)
index 0000000..b98f1f5
--- /dev/null
+++ b/fd/12c218854821675af324c3b3e243ec5a196569
@@ -0,0 +1,119 @@
+Return-Path: <amdragon@gmail.com>\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 569F0431FD0\r
+       for <notmuch@notmuchmail.org>; Mon, 21 Mar 2011 00:51:35 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.699\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5\r
+       tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001,\r
+       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 fZ2K+g46rpkb for <notmuch@notmuchmail.org>;\r
+       Mon, 21 Mar 2011 00:51:34 -0700 (PDT)\r
+Received: from mail-qy0-f174.google.com (mail-qy0-f174.google.com\r
+       [209.85.216.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id 2766F431FB5\r
+       for <notmuch@notmuchmail.org>; Mon, 21 Mar 2011 00:51:33 -0700 (PDT)\r
+Received: by qyk7 with SMTP id 7so2250167qyk.5\r
+       for <notmuch@notmuchmail.org>; Mon, 21 Mar 2011 00:51:33 -0700 (PDT)\r
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
+       h=domainkey-signature:mime-version:sender:in-reply-to:references:date\r
+       :x-google-sender-auth:message-id:subject:from:to:cc:content-type\r
+       :content-transfer-encoding;\r
+       bh=hm3jcPN8qUxILKUKWxLJT8tIQvOfRiufZBW7C0e19O0=;\r
+       b=MCbA5S3Fqz01vJ3PmK77h6HWSuAtItjdoYqVZcVf2kbnt5LAFvV3qKQ3DBTQX4J5M8\r
+       6sIo9ziBNs3/8VCrK4tMYxkLBRnVCWVbnDSoV1WMoKm4vdZWxUxtmCCt+dwm/S4mBOVv\r
+       CU984ywVYH7hQekYR/1+uz+4g/vIKXK/Pu8bU=\r
+DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;\r
+       h=mime-version:sender:in-reply-to:references:date\r
+       :x-google-sender-auth:message-id:subject:from:to:cc:content-type\r
+       :content-transfer-encoding;\r
+       b=GfPf3RLw8Yme+M1S/zTWV01ofphh6JVzhqW7hj9y+coU3v1yJdPxjCSlj+J77omlpW\r
+       vhlpabAbvsxZJvfffmHZpXBiMriwz+8N+AfP09oNi/rShkneTP0AJXBivmdAFmWmphae\r
+       N18k/9zONQ6HAvjlqA6ku5C3MnSm0H8NCNz74=\r
+MIME-Version: 1.0\r
+Received: by 10.229.102.209 with SMTP id h17mr2973113qco.102.1300693893310;\r
+       Mon, 21 Mar 2011 00:51:33 -0700 (PDT)\r
+Sender: amdragon@gmail.com\r
+Received: by 10.229.30.68 with HTTP; Mon, 21 Mar 2011 00:51:33 -0700 (PDT)\r
+In-Reply-To: <87k4g6vxrw.fsf@steelpick.2x.cz>\r
+References: <87d3nhe3g9.fsf@steelpick.2x.cz>\r
+       <AANLkTinW_n+zMtLC-fy=naUGsAiFDwdd-mAqSWEDvF=W@mail.gmail.com>\r
+       <AANLkTinPph9Lj8h3UztQ74qMaaBVKkXB0rbiLeTX2GmW@mail.gmail.com>\r
+       <87lj0m8ki5.fsf@yoom.home.cworth.org>\r
+       <20110311024730.GA31011@mit.edu>\r
+       <8762rq8byr.fsf@yoom.home.cworth.org>\r
+       <87k4g6vxrw.fsf@steelpick.2x.cz>\r
+Date: Mon, 21 Mar 2011 03:51:33 -0400\r
+X-Google-Sender-Auth: wCdKaB8v8EpqVqxn1rQltr9HwMM\r
+Message-ID: <AANLkTinzJrdA24V60LBUavUn1arMGQ14CM5ZGwCfGfcV@mail.gmail.com>\r
+Subject: Re: Xapian locking errors with custom query parser\r
+From: Austin Clements <amdragon@mit.edu>\r
+To: Michal Sojka <sojkam1@fel.cvut.cz>\r
+Content-Type: text/plain; charset=ISO-8859-1\r
+Content-Transfer-Encoding: quoted-printable\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: Mon, 21 Mar 2011 07:51:35 -0000\r
+\r
+On Fri, Mar 11, 2011 at 3:58 AM, Michal Sojka <sojkam1@fel.cvut.cz> wrote:\r
+> On Fri, 11 Mar 2011, Carl Worth wrote:\r
+>> I've finally had a chance to start looking at this.\r
+>\r
+> [...]\r
+>\r
+>> 1. For "new" search features (ADJ,NEAR,etc.) I do not have a strong\r
+>> =A0 =A0interest in compatibility with Xapian.\r
+>>\r
+>> =A0 =A0I was very careful when I wrote the documentation for the notmuch\r
+>> =A0 =A0search syntax to only document features that I had used and teste=\r
+d,\r
+>> =A0 =A0and that I was sure I wanted. (I was already thinking forward to\r
+>> =A0 =A0perhaps writing a custom query parser at some point.)\r
+>>\r
+>> =A0 =A0So you should really use our existing documentation as the\r
+>> =A0 =A0guide. Please implement and test what it says.\r
+>>\r
+>> =A0 =A0Beyond that, if you want to add additional features not mentioned=\r
+ in\r
+>> =A0 =A0our documentation, then feel free to, and there's no good reason =\r
+not\r
+>> =A0 =A0to be Xapian compatible. But I also don't think there's a strong\r
+>> =A0 =A0reason that we have to be compatible.\r
+>\r
+> Additionally, I'd suggest to support value range queries for dates with\r
+> ".." syntax. Besides that some users may relay on this syntax, I use\r
+> date searches a lot and with custom query parser I have to type\r
+> "after:yesterday", which is unnecessarily long. I wish that\r
+> "yesterday..", which is much easier to type, would do the same.\r
+> Similarly, "mon..wed" would be easier to type than "after:mon\r
+> before:wed". What do you think?\r
+\r
+Personally, I just don't understand the .. range syntax, which is why\r
+I left it out (also, I was following the example in the TODO file).\r
+It's completely inconsistent with the rest of the query syntax and\r
+makes no indication of what it's a range over (what if you had other\r
+ordinal values to search over?  what if you could search by the\r
+received date or the sent date?).\r
+\r
+What about something like "date:mon..wed"?  That's consistent with the\r
+query syntax (the range part becomes part of the date syntax, not part\r
+of the top-level query syntax), it indicates the domain of the search\r
+term in a clean and extensible way, and it's succinct.\r