QueryParser corner cases

[Olly Betts]

There are quite a few cases which we probably don't handle as well as we could (sometimes it's not totally clear what the behaviour should be), so let's make a list here and see if we can find resolutions, or decide the current behaviour is fine.

With FLAG_SYNONYM this causes reparsing so parse as foo abc def (we just ignore ~ unless the next character is a word character, so without the "foo:" prefix, ~ is just ignored):

~foo:(abc def)

Assuming "foo" is set as a non-boolean prefix, it should probably parse as synonyms for the two terms, so the same as:

~foo:abc ~foo:def

[Olly Betts]

Not a release blocker - we can fix these in 1.4.x without an ABI break.

[Olly Betts]

I wonder if we should require whitespace around operators (or a parenthesis is OK - e.g. a AND(b OR c)AND d should parse with 3 operators) but currently some punctuation is treated like a space here, but parentheses don't work:

$ quest 'foo=AND=bar'
Parsed Query: Query((foo@1 AND Zbar@2))
No database specified so not running the query.
$ quest 'a AND(b OR c)AND d'
Parsed Query: Query((Za@1 OR and@2 OR (Zb@3 OR Zc@5) OR Zd@7))
No database specified so not running the query.

[Olly Betts]

(tested those last cases with 1.4.22 and git master)

[Olly Betts]

~foo:"abc def" [...] should probably do a multi-word synonym expansion.

I actually have a patch which implements this part so we can easily do this part for 1.5.0.

[Olly Betts]

Replying to Olly Betts:

~foo:"abc def" [...] should probably do a multi-word synonym expansion.

I actually have a patch which implements this part so we can easily do this part for 1.5.0.

Applied in 8c723ec78753e9ae701261eb388ef4b7855aff5e. The other case probably isn't for 1.5.0.