85/a1e8815c1474cff4688e583ec19c05d2cddae5

   1 Return-Path: <cworth@cworth.org>\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 C4EBB429E20\r
   6         for <notmuch@notmuchmail.org>; Thu, 10 Mar 2011 21:26:06 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.99\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5\r
  12         tests=[ALL_TRUSTED=-1, T_MIME_NO_TEXT=0.01] autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id fZealZKe9vIN; Thu, 10 Mar 2011 21:26:05 -0800 (PST)\r
  16 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  17         by olra.theworths.org (Postfix) with ESMTP id 94963431FB5;\r
  18         Thu, 10 Mar 2011 21:26:05 -0800 (PST)\r
  19 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  20         id 1ED5325401B; Thu, 10 Mar 2011 21:26:05 -0800 (PST)\r
  21 From: Carl Worth <cworth@cworth.org>\r
  22 To: Austin Clements <amdragon@MIT.EDU>\r
  23 Subject: Re: Xapian locking errors with custom query parser\r
  24 In-Reply-To: <20110311024730.GA31011@mit.edu>\r
  25 References: <87d3nhe3g9.fsf@steelpick.2x.cz>\r
  26         <AANLkTinW_n+zMtLC-fy=naUGsAiFDwdd-mAqSWEDvF=W@mail.gmail.com>\r
  27         <AANLkTinPph9Lj8h3UztQ74qMaaBVKkXB0rbiLeTX2GmW@mail.gmail.com>\r
  28         <87lj0m8ki5.fsf@yoom.home.cworth.org>\r
  29         <20110311024730.GA31011@mit.edu>\r
  30 User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.2.1\r
  31         (i486-pc-linux-gnu)\r
  32 Date: Thu, 10 Mar 2011 21:26:04 -0800\r
  33 Message-ID: <8762rq8byr.fsf@yoom.home.cworth.org>\r
  34 MIME-Version: 1.0\r
  35 Content-Type: multipart/signed; boundary="=-=-=";\r
  36         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  37 Cc: notmuch@notmuchmail.org\r
  38 X-BeenThere: notmuch@notmuchmail.org\r
  39 X-Mailman-Version: 2.1.13\r
  40 Precedence: list\r
  41 List-Id: "Use and development of the notmuch mail system."\r
  42         <notmuch.notmuchmail.org>\r
  43 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  44         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  45 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  46 List-Post: <mailto:notmuch@notmuchmail.org>\r
  47 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  48 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  49         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  50 X-List-Received-Date: Fri, 11 Mar 2011 05:26:06 -0000\r
  51 \r
  52 --=-=-=\r
  53 Content-Transfer-Encoding: quoted-printable\r
  54 \r
  55 On Thu, 10 Mar 2011 21:47:30 -0500, Austin Clements <amdragon@MIT.EDU> wrot=\r
  56 e:\r
  57 > Yes, qparser-3 is ready for you, and has this fix folded in to it (see\r
  58 > id:20110202050336.GB28537@mit.edu).\r
  59 \r
  60 Thanks.\r
  61 \r
  62 I've finally had a chance to start looking at this.\r
  63 \r
  64 The first thing that caught my eye was this question:\r
  65 \r
  66 > +/* XXX notmuch currently registers "tag" as an exclusive boolean\r
  67 > + * prefix, which means queries like "tag:x tag:y" will return messages\r
  68 > + * with tag x OR tag y.  Is this intentional? */\r
  69 \r
  70 This isn't "intentional" in the sense that it is desired, no.\r
  71 \r
  72 Our documentation for the search syntax says:\r
  73 \r
  74     In addition to individual terms, multiple terms can  be  combined  with\r
  75     Boolean  operators  ( and, or, not , etc.). Each term in the query will\r
  76     be implicitly connected by a logical AND if  no  explicit  operator  is\r
  77     provided,  (except  that  terms with a common prefix will be implicitly\r
  78     combined with OR until we get Xapian defect #402 fixed).\r
  79 \r
  80 So, when I originally wrote this code, the add_boolean_prefix function\r
  81 didn't have the "exclusive" parameter that it has now. So that's\r
  82 something to fix.\r
  83 \r
  84 The next thing I notice is quite a lot of concern in the testing for\r
  85 whether things were precisely Xapian compatible or not. I have two\r
  86 different opinions about this:\r
  87 \r
  88 1. For "new" search features (ADJ,NEAR,etc.) I do not have a strong\r
  89    interest in compatibility with Xapian.\r
  90 \r
  91    I was very careful when I wrote the documentation for the notmuch\r
  92    search syntax to only document features that I had used and tested,\r
  93    and that I was sure I wanted. (I was already thinking forward to\r
  94    perhaps writing a custom query parser at some point.)\r
  95 \r
  96    So you should really use our existing documentation as the\r
  97    guide. Please implement and test what it says.\r
  98 \r
  99    Beyond that, if you want to add additional features not mentioned in\r
 100    our documentation, then feel free to, and there's no good reason not\r
 101    to be Xapian compatible. But I also don't think there's a strong\r
 102    reason that we have to be compatible.\r
 103 \r
 104    Of course, for any new features here I would also like to see the\r
 105    documentation be updated.\r
 106 \r
 107 2. For term splitting I do have a strong interest in Xapian compatibility.\r
 108 \r
 109    The difference here is that we aren't doing our own indexing, but\r
 110    instead relying on Xapian to do that for us, and we have also never\r
 111    carefully documented how the term splitting happens.\r
 112 \r
 113    What I want to happen here is that if a user grabs a chunk of text\r
 114    from an email, (say, "x#y"), and searches for it, that notmuch will\r
 115    find emails that actually contain that text. So if the indexer and\r
 116    the query parser disagree about something like this, then notmuch can\r
 117    break badly.\r
 118 \r
 119    I don't know how well notmuch currently meets that requirement, but\r
 120    I've been trusting in consistent term-splitting in the indexer and\r
 121    query-parser to help with this. So the frequent comments about\r
 122    incompatibility along these lines in your patches make me nervous.\r
 123 \r
 124    Can you enlighten me more about the compatibility differences in this\r
 125    area, and how things might break here?\r
 126 \r
 127 > Interesting.  I could see this being useful for decluttering\r
 128 > superseded review branches, though that would require renaming\r
 129 > superseded branches, which always causes a mess.\r
 130 \r
 131 Deleting any superseded for-cworth branch would never cause me any\r
 132 problem. If you had other consumers of your branches that wouldn't be as\r
 133 happy with branch names disappearing, then you might want to just let\r
 134 them have another name outside the "for-cworth" space.\r
 135 \r
 136 Anyway, it's just one idea for helping me get some more information from\r
 137 git.\r
 138 \r
 139 =2DCarl\r
 140 \r
 141 =2D-=20\r
 142 carl.d.worth@intel.com\r
 143 \r
 144 --=-=-=\r
 145 Content-Type: application/pgp-signature\r
 146 \r
 147 -----BEGIN PGP SIGNATURE-----\r
 148 Version: GnuPG v1.4.10 (GNU/Linux)\r
 149 \r
 150 iD8DBQFNebJs6JDdNq8qSWgRAqzHAJ9b5R9tAFYaoOLg3nNUSzrzsuCfdgCgjDuz\r
 151 VkPEm9Osy6+wz3mF9T7lv+A=\r
 152 =2nE4\r
 153 -----END PGP SIGNATURE-----\r
 154 --=-=-=--\r