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
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
32 Date: Thu, 10 Mar 2011 21:26:04 -0800
\r
33 Message-ID: <8762rq8byr.fsf@yoom.home.cworth.org>
\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
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
53 Content-Transfer-Encoding: quoted-printable
\r
55 On Thu, 10 Mar 2011 21:47:30 -0500, Austin Clements <amdragon@MIT.EDU> wrot=
\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
62 I've finally had a chance to start looking at this.
\r
64 The first thing that caught my eye was this question:
\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
70 This isn't "intentional" in the sense that it is desired, no.
\r
72 Our documentation for the search syntax says:
\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
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
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
88 1. For "new" search features (ADJ,NEAR,etc.) I do not have a strong
\r
89 interest in compatibility with Xapian.
\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
96 So you should really use our existing documentation as the
\r
97 guide. Please implement and test what it says.
\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
104 Of course, for any new features here I would also like to see the
\r
105 documentation be updated.
\r
107 2. For term splitting I do have a strong interest in Xapian compatibility.
\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
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
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
124 Can you enlighten me more about the compatibility differences in this
\r
125 area, and how things might break here?
\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
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
136 Anyway, it's just one idea for helping me get some more information from
\r
142 carl.d.worth@intel.com
\r
145 Content-Type: application/pgp-signature
\r
147 -----BEGIN PGP SIGNATURE-----
\r
148 Version: GnuPG v1.4.10 (GNU/Linux)
\r
150 iD8DBQFNebJs6JDdNq8qSWgRAqzHAJ9b5R9tAFYaoOLg3nNUSzrzsuCfdgCgjDuz
\r
151 VkPEm9Osy6+wz3mF9T7lv+A=
\r
153 -----END PGP SIGNATURE-----
\r