98/3f54db0b3afdd1b95276596c03a5208026dc1a

   1 Return-Path: <amdragon@gmail.com>\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 BF7DB431FD0\r
   6         for <notmuch@notmuchmail.org>; Mon, 21 Mar 2011 00:41:29 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.699\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5\r
  12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001,\r
  13         RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id 7GLGsTz19uKD for <notmuch@notmuchmail.org>;\r
  17         Mon, 21 Mar 2011 00:41:28 -0700 (PDT)\r
  18 Received: from mail-qw0-f53.google.com (mail-qw0-f53.google.com\r
  19         [209.85.216.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
  20         (No client certificate requested)\r
  21         by olra.theworths.org (Postfix) with ESMTPS id AB0B3431FB5\r
  22         for <notmuch@notmuchmail.org>; Mon, 21 Mar 2011 00:41:28 -0700 (PDT)\r
  23 Received: by qwc9 with SMTP id 9so4293702qwc.26\r
  24         for <notmuch@notmuchmail.org>; Mon, 21 Mar 2011 00:41:28 -0700 (PDT)\r
  25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
  26         h=domainkey-signature:mime-version:sender:in-reply-to:references:date\r
  27         :x-google-sender-auth:message-id:subject:from:to:cc:content-type\r
  28         :content-transfer-encoding;\r
  29         bh=syKIE+qHf4KBL7NCu+5ZSc5Z+xESEwtYuCuGfAxougY=;\r
  30         b=YVj/8UmPQQvDe0QAq09jbMDFNL4Scuq6nj1zhTYuvzy9pqlwdI01uUNcDgtrUzQhsl\r
  31         bTsEY6pW1R6/Ns6LIdM/slIXyXL4vUWmAqrUNB03HNGOn70+GW+A7qT8T/4CIX9vcH57\r
  32         3eUzCHq4lVbeqsoiMMJdolGGUQ+v6E7dZTjpk=\r
  33 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;\r
  34         h=mime-version:sender:in-reply-to:references:date\r
  35         :x-google-sender-auth:message-id:subject:from:to:cc:content-type\r
  36         :content-transfer-encoding;\r
  37         b=wiUBF8qNYDpnV6NoZu+bMzmkd6H4jVaUairzaUlnm1w5/hO+ZMX3N1bRh6eBV4ekFY\r
  38         zLCVfk5/JYnl+HOCqFeBvViEe/kEMAe061kPIGmcKbNHvscGa/ur6H3y0I2rE1SbI4Nx\r
  39         yzhRKRjXik4R5yFs3WtQAcCwUXCGu/P4f5Ij4=\r
  40 MIME-Version: 1.0\r
  41 Received: by 10.229.130.168 with SMTP id t40mr1633127qcs.140.1300693288071;\r
  42         Mon, 21 Mar 2011 00:41:28 -0700 (PDT)\r
  43 Sender: amdragon@gmail.com\r
  44 Received: by 10.229.30.68 with HTTP; Mon, 21 Mar 2011 00:41:28 -0700 (PDT)\r
  45 In-Reply-To: <8762rq8byr.fsf@yoom.home.cworth.org>\r
  46 References: <87d3nhe3g9.fsf@steelpick.2x.cz>\r
  47         <AANLkTinW_n+zMtLC-fy=naUGsAiFDwdd-mAqSWEDvF=W@mail.gmail.com>\r
  48         <AANLkTinPph9Lj8h3UztQ74qMaaBVKkXB0rbiLeTX2GmW@mail.gmail.com>\r
  49         <87lj0m8ki5.fsf@yoom.home.cworth.org>\r
  50         <20110311024730.GA31011@mit.edu>\r
  51         <8762rq8byr.fsf@yoom.home.cworth.org>\r
  52 Date: Mon, 21 Mar 2011 03:41:28 -0400\r
  53 X-Google-Sender-Auth: pxEXPBciSaHTqioTOCCPlZc4d3M\r
  54 Message-ID: <AANLkTin_g8Y9SDN7Fm8ZejTpmuKcwDq5PX1yB+j9xpEV@mail.gmail.com>\r
  55 Subject: Re: Xapian locking errors with custom query parser\r
  56 From: Austin Clements <amdragon@mit.edu>\r
  57 To: Carl Worth <cworth@cworth.org>\r
  58 Content-Type: text/plain; charset=ISO-8859-1\r
  59 Content-Transfer-Encoding: quoted-printable\r
  60 Cc: notmuch@notmuchmail.org\r
  61 X-BeenThere: notmuch@notmuchmail.org\r
  62 X-Mailman-Version: 2.1.13\r
  63 Precedence: list\r
  64 List-Id: "Use and development of the notmuch mail system."\r
  65         <notmuch.notmuchmail.org>\r
  66 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  67         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  68 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  69 List-Post: <mailto:notmuch@notmuchmail.org>\r
  70 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  71 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  72         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  73 X-List-Received-Date: Mon, 21 Mar 2011 07:41:30 -0000\r
  74 \r
  75 I haven't made any changes to the query parser yet, but I wanted to\r
  76 reply to your questions.  (I might not get a chance to change things\r
  77 for a while; I spent this weekend catching my breath and dealing with\r
  78 all of the things I punted over the past few weeks and tomorrow it's\r
  79 back to a different grind.  Whoever said being a grad student was\r
  80 hitting the snooze button on life was a liar.)\r
  81 \r
  82 Responses inline.\r
  83 \r
  84 On Fri, Mar 11, 2011 at 12:26 AM, Carl Worth <cworth@cworth.org> wrote:\r
  85 > On Thu, 10 Mar 2011 21:47:30 -0500, Austin Clements <amdragon@MIT.EDU> wr=\r
  86 ote:\r
  87 >> Yes, qparser-3 is ready for you, and has this fix folded in to it (see\r
  88 >> id:20110202050336.GB28537@mit.edu).\r
  89 >\r
  90 > Thanks.\r
  91 >\r
  92 > I've finally had a chance to start looking at this.\r
  93 >\r
  94 > The first thing that caught my eye was this question:\r
  95 >\r
  96 >> +/* XXX notmuch currently registers "tag" as an exclusive boolean\r
  97 >> + * prefix, which means queries like "tag:x tag:y" will return messages\r
  98 >> + * with tag x OR tag y. =A0Is this intentional? */\r
  99 >\r
 100 > This isn't "intentional" in the sense that it is desired, no.\r
 101 >\r
 102 > Our documentation for the search syntax says:\r
 103 >\r
 104 > =A0 =A0In addition to individual terms, multiple terms can =A0be =A0combi=\r
 105 ned =A0with\r
 106 > =A0 =A0Boolean =A0operators =A0( and, or, not , etc.). Each term in the q=\r
 107 uery will\r
 108 > =A0 =A0be implicitly connected by a logical AND if =A0no =A0explicit =A0o=\r
 109 perator =A0is\r
 110 > =A0 =A0provided, =A0(except =A0that =A0terms with a common prefix will be=\r
 111  implicitly\r
 112 > =A0 =A0combined with OR until we get Xapian defect #402 fixed).\r
 113 >\r
 114 > So, when I originally wrote this code, the add_boolean_prefix function\r
 115 > didn't have the "exclusive" parameter that it has now. So that's\r
 116 > something to fix.\r
 117 \r
 118 Okay.  I suppose that this applies to all boolean prefixes, then, and\r
 119 not just tag.  That actually simplifies parse_prob, since it can treat\r
 120 boolean prefixed terms just like other terms and won't have to match\r
 121 up identical prefixes.\r
 122 \r
 123 I suppose a separate patch should first change the boolean prefixes to\r
 124 exclusive to make sure the custom parser is a drop-in replacement.\r
 125 \r
 126 > The next thing I notice is quite a lot of concern in the testing for\r
 127 > whether things were precisely Xapian compatible or not. I have two\r
 128 > different opinions about this:\r
 129 >\r
 130 > 1. For "new" search features (ADJ,NEAR,etc.) I do not have a strong\r
 131 > =A0 interest in compatibility with Xapian.\r
 132 >\r
 133 > =A0 I was very careful when I wrote the documentation for the notmuch\r
 134 > =A0 search syntax to only document features that I had used and tested,\r
 135 > =A0 and that I was sure I wanted. (I was already thinking forward to\r
 136 > =A0 perhaps writing a custom query parser at some point.)\r
 137 >\r
 138 > =A0 So you should really use our existing documentation as the\r
 139 > =A0 guide. Please implement and test what it says.\r
 140 >\r
 141 > =A0 Beyond that, if you want to add additional features not mentioned in\r
 142 > =A0 our documentation, then feel free to, and there's no good reason not\r
 143 > =A0 to be Xapian compatible. But I also don't think there's a strong\r
 144 > =A0 reason that we have to be compatible.\r
 145 >\r
 146 > =A0 Of course, for any new features here I would also like to see the\r
 147 > =A0 documentation be updated.\r
 148 \r
 149 I guess I didn't know what "etc" meant in the list of supported\r
 150 boolean operators, so I took it to mean "whatever Xapian does".  I\r
 151 leaned hard on Xapian compatibility because I didn't want to beak\r
 152 anybody's setup, but I'm happy to strip out compatibility stuff\r
 153 (especially NEAR and ADJ; those add a lot of complexity!)\r
 154 \r
 155 Besides NEAR and ADJ, the only features I can think of that aren't in\r
 156 the documentation but that I implemented are + and -.  But I think a\r
 157 lot of people use these and they're really handy, so perhaps they\r
 158 should be documented instead of being stripped.\r
 159 \r
 160 > 2. For term splitting I do have a strong interest in Xapian compatibility=\r
 161 .\r
 162 >\r
 163 > =A0 The difference here is that we aren't doing our own indexing, but\r
 164 > =A0 instead relying on Xapian to do that for us, and we have also never\r
 165 > =A0 carefully documented how the term splitting happens.\r
 166 >\r
 167 > =A0 What I want to happen here is that if a user grabs a chunk of text\r
 168 > =A0 from an email, (say, "x#y"), and searches for it, that notmuch will\r
 169 > =A0 find emails that actually contain that text. So if the indexer and\r
 170 > =A0 the query parser disagree about something like this, then notmuch can\r
 171 > =A0 break badly.\r
 172 >\r
 173 > =A0 I don't know how well notmuch currently meets that requirement, but\r
 174 > =A0 I've been trusting in consistent term-splitting in the indexer and\r
 175 > =A0 query-parser to help with this. So the frequent comments about\r
 176 > =A0 incompatibility along these lines in your patches make me nervous.\r
 177 >\r
 178 > =A0 Can you enlighten me more about the compatibility differences in this\r
 179 > =A0 area, and how things might break here?\r
 180 \r
 181 In some sense, the term splitting the custom query parser does is more\r
 182 Xapian-compatible than the Xapian parser's term splitting.  The custom\r
 183 query parser uses the exact same TermGenerator that notmuch uses to\r
 184 split documents in the first place, so the query term splitting will\r
 185 be identical.  In fact, your x#y example *won't* do what you want with\r
 186 the Xapian parser (it will be equivalent to x AND y), but it will with\r
 187 the custom parser (it will be like "x y", which is as close as it can\r
 188 get since Xapian doesn't index the #).\r
 189 \r
 190 The real difference between the Xapian parser and the custom parser\r
 191 lies in how they split *implicit phrases*.  In the Xapian parser,\r
 192 characters that split terms are treated in one of two different ways:\r
 193 they can either just split a term, but keep the resulting terms\r
 194 together in a phrase; or they separate phrases '#' does the latter,\r
 195 which is why x#y becomes x AND y.  In the custom parser, only\r
 196 whitespace, '(', ')' and '"' separate phrases, and each phrase is then\r
 197 split into terms using the TermGenerator.  Hence, the terms you get\r
 198 are Xapian-compatible, but the custom parser treats more things as\r
 199 phrases (using much more understandable rules).\r
 200 \r
 201 I hope that addresses your concern with the term splitting.  If not,\r
 202 please let me know.\r