From mboxrd@z Thu Jan  1 00:00:00 1970
From: rlane@club.cc.cmu.edu (Rich Lane)
Date: Thu, 03 Sep 2009 12:52:27 -0400
Subject: [sup-talk] [PATCH 0/18] Xapian-based index
In-Reply-To: <1251792282-sup-2057@cannonball>
References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
	<1245854803-sup-4481@entry> <1245864733-sup-1216@entry>
	<loom.20090625T222159-861@post.gmane.org>
	<1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse>
	<20090723102325.GA4291@chistera.yi.org>
	<1248497184-sup-939@pion.club.cc.cmu.edu>
	<1248513425-sup-2484@chistera.yi.org>
	<1248550384-sup-74@pion.club.cc.cmu.edu>
	<1248709681-sup-4141@entry> <1248713376-sup-5163@cannonball>
	<1251792282-sup-2057@cannonball>
Message-ID: <1251996241-sup-5112@zyrg.net>

Excerpts from Ingmar Vanhassel's message of Tue Sep 01 04:07:27 -0400 2009:
> Excerpts from Ingmar Vanhassel's message of Mon Jul 27 18:56:28 +0200 2009:
> > Excerpts from William Morgan's message of Mon Jul 27 17:48:38 +0200 2009:
> > > Reformatted excerpts from Rich Lane's message of 2009-07-25:
> > > > One issue I've noticed is that removing labels from messages doesn't
> > > > always immediately work.
> > > 
> > > Is this true even after you sync changes to the index? What about if you
> > > reload the label list buffer? ('@')
> > 
> > It's true in both cases. Even after a sync, 'U' still produces read
> > messages (among unread), and a search for label:foo has threads without
> > that label. If you quit sup & restart it things work as expected for a
> > while.
> 
> I can still reproduce this for a more specific case, with xapian 1.0.15.
> 
> Searching for is:unread (hit U), works as expected. When I filter
> that with threads having a second label (hit |, label:foo), then it
> shows threads with label:foo, but it loses the is:unread constraint.
> 
> Same for immediately doing is:unread label:foo, which gives me unread
> threads, but not always with the foo label.

I've reproduced this and it looks like a query parsing problem. Multiple
terms on the same field are OR'd together instead of AND [1]. Adding an
explicit AND works. I'll see if Xapian::QueryParser can be convinced to
do what we want here.

[1] http://trac.xapian.org/ticket/157