unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: Olly Betts <olly@survex.com>
To: Dmitry Kurochkin <dmitry.kurochkin@gmail.com>
Cc: notmuch@notmuchmail.org
Subject: Re: [PATCH 2/5] Add quotes around id:"message-id" queries.
Date: Mon, 5 Jul 2010 08:33:50 +0100	[thread overview]
Message-ID: <20100705073350.GB4161@survex.com> (raw)
In-Reply-To: <87bpaq6nm9.fsf@gmail.com>

On Fri, Jul 02, 2010 at 05:04:46PM +0400, Dmitry Kurochkin wrote:
> On Fri, 2 Jul 2010 04:41:43 +0000 (UTC), Olly Betts <olly@survex.com> wrote:
> > On 2010-07-01, Dmitry Kurochkin wrote:
> > > -  (concat "id:" (notmuch-show-get-prop :id props)))
> > > +  (concat "id:\"" (notmuch-show-get-prop :id props) "\""))
> > 
> > This is probably a good idea (the ".." example is arguably a Xapian bug so
> > that should be fixed soon, but you find all sorts of junk in message-ids.
> 
> If I comment out add_valuerangeprocessor call in
> notmuch_database_open(), ids with .. are matched fine with no quotes.

Yes, the code which checks for ranges is disabled if there are no possible
ranges to find.

> So it seems that xapian uses the ValueRangeProcessor for all terms
> while it should be used for one value parsing only. Is this correct?

The issue is that if there's a ".." in there you have to ask the VRPs to
find out if it is a range they understand or not, so they have to be called
first in such cases (otherwise the same prefix couldn't be made to work for
ranges and single term filters).  There needs to be some sort of fallback
to considering boolean filters if there isn't a valid range though.

> Is there a xapian bug for this?

I couldn't find a ticket for it, but I was aware of the issue.

I've committed a fix to Xapian now (r14790 on trunk), which should be in
Xapian 1.2.3 when it gets released.

> I have found a xapian bug #128 "Allow queryparser to treat some prefixes
> as literal text". Seems to be just what we need here. Perhaps instead of
> quoting in emacs client, we can wait for the value range parsing fix
> (can be fixed in minor release?) and use #128 when it is available. IMHO
> should be good enought in most cases. What do you think?

The main problem at the moment is with "..", which is now fixed on trunk.
So any Xapian version with #128 fully addressed will handle ".." in
message-ids fine anyway.

With current trunk, message-ids with whitespace or ')' in will still
misbehave unless you quote them.  If the "FieldProcessor" idea in #128 were
implemented, you could arrange for whitespace and ')' to be included, but
then it would be impossible to end a message-id term - it would span to the
end of the query string, which I think would surprise most users.

The ability to quote terms discussed in #128 is already implemented (that
is what you've been using!) and I think that using this selectively is
probably the best way to deal with this.

If you only try to quote message-ids which either:

* contain whitespace, "..", or ')'
* start with '"'

Then the only cases which break with older Xapian will be those which
wouldn't work there anyway, plus message-ids which start with a '"' (which 
seem rare - I couldn't find any in my mail folders).

Cheers,
    Olly

  reply	other threads:[~2010-07-05  7:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-01 16:08 [PATCH 0/5] some fixes for emacs client Dmitry Kurochkin
2010-07-01 16:08 ` [PATCH 1/5] Use notmuch-show-get-message-id in notmuch-show-get-bodypart-content Dmitry Kurochkin
2010-07-01 16:08 ` [PATCH 2/5] Add quotes around id:"message-id" queries Dmitry Kurochkin
2010-07-02  4:41   ` Olly Betts
2010-07-02 13:04     ` Dmitry Kurochkin
2010-07-05  7:33       ` Olly Betts [this message]
2010-07-01 16:08 ` [PATCH 3/5] Use message-field-value instead of message-fetch-field Dmitry Kurochkin
2010-07-01 16:08 ` [PATCH 4/5] Add notmuch-hook. Called when notmuch is started, before notmuch-hello buffer is created Dmitry Kurochkin
2010-07-01 16:08 ` [PATCH 5/5] Add notmuch-hello-hook. Called every time notmuch-hello buffer is updated Dmitry Kurochkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://notmuchmail.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100705073350.GB4161@survex.com \
    --to=olly@survex.com \
    --cc=dmitry.kurochkin@gmail.com \
    --cc=notmuch@notmuchmail.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).