similar to: synonym expansion for boolean prefixes.

Olly Betts <olly at survex.com> writes: > A better option for this is probably a FieldProcessor - you set one for > a prefix and the it gets passed the value and returns a Query object > for it. E.g. in lua (where you can just pass an anon function for the > FieldProcessor - we ought to support C++11 lambdas for such things): [snip] > To achieve this with synonyms in a

On Sun, Dec 27, 2015 at 11:24:36PM -0400, David Bremner wrote: > I have an application for synonyms for tags in in notmuch, which means > synonym expansion for a particular boolean prefix. I have a vague memory > of Olly telling me this doesn't work, but I'm not sure about the > details. Yes, synonym expansion isn't done for boolean terms (only "probabilistic

Olly Betts <olly at survex.com> writes: > On Tue, Jan 05, 2016 at 08:43:13AM -0400, David Bremner wrote: >> Olly Betts <olly at survex.com> writes: >> >> > To achieve this with synonyms in a configurable way you'd need to >> > rewrite the synonyms in the database to match the current configuration, >> > so it's not as dynamic as the

On Tue, Jan 05, 2016 at 08:43:13AM -0400, David Bremner wrote: > Olly Betts <olly at survex.com> writes: > > > To achieve this with synonyms in a configurable way you'd need to > > rewrite the synonyms in the database to match the current configuration, > > so it's not as dynamic as the above. > > Well, the configuration needs to be somewhere. Would

Olly Betts <olly at survex.com> writes: > A better option for this is probably a FieldProcessor - you set one for > a prefix and the it gets passed the value and returns a Query object > for it. E.g. in lua (where you can just pass an anon function for the > FieldProcessor - we ought to support C++11 lambdas for such things): By the way, is there an online version of the

Hi all, public-inbox allows searching for git blob names (e.g. "badc0ffee") in patches. Initially, I chose to use add_prefix for probabilistic terms, since I assumed it could be a superset of what boolean searching offered. Unfortunately, it doesn't seem to be the case because stemming is interfering. So switching to boolean filtering seems to work; and it is fine for mechanical

Very few people seem to be using synonym in Xapian, I recently found some problems in the use of synonyms. Normally, I think we should not contain any prefix info in synonym table except that 'Z'. For example, I have the following synonyms and prefix info: db.add_synonym("search", "find"); db.add_synonym("Zsearch", "Zfind");

olly wrote: > SVN root: svn://svn.xapian.org/xapian > Changes by: olly > Revision: 9476 > Date: 2007-10-19 03:47:11 +0100 (Fri, 19 Oct 2007) > > Log message (14 lines): > include/xapian/queryparser.h,queryparser/queryparser.cc, > queryparser/queryparser.lemony,queryparser/queryparser_internal.h, > tests/queryparsertest.cc: Since calling

Today we noticed that keywords can't be searched as prefixed terms. Or that's what it looks like anyway. I tested and, or, and not. ╰─% NOTMUCH_DEBUG_QUERY=y notmuch search 'subject:"and"' Query string is: subject:"and" notmuch search: A Xapian exception occurred A Xapian exception occurred parsing query: Syntax: <expression> AND <expression> Query

Dear group, There are postings on extracting partial string using sub()/gsub()/gsubfn() but I still couldn't figure this one out. Supposed I am pulling the synonyms of "help" using synonyms("help") from wordnet and get the followings: > synonyms("help") [1] "c(\"aid\", \"assist\", \"assistance\", \"help\")"

I've got a small test database setup with one record. $ delve -r 1 -V /tmp/1/ Values for record #1: 0:DD4F2162FFFF0E43741A4A1C2B8EC0E7 1:./Text_page_scan_2.jpg 2:jpg 3:.jpg Term List for record #1: E:.jpg P:./Text_page_scan_2.jpg Q:DD4F2162FFFF0E43741A4A1C2B8EC0E7 T:jpg The terms were added with lines like this: doc.add_term(string("P:") + path); Problem is, I can't seem to

Hello, include <iostream>#include <string>#include <xapian.h>struct document{ std::string title; std::string content; std::string url;}; void indexData(document d) { try { Xapian::WritableDatabase db("/Users/ramesh/Desktop/xapian", Xapian::DB_CREATE_OR_OPEN); Xapian::TermGenerator indexer; Xapian::Stem

Hello, include <iostream>#include <string>#include <xapian.h>struct document{ std::string title; std::string content; std::string url;}; void indexData(document d) { try { Xapian::WritableDatabase db("/Users/ramesh/Desktop/xapian", Xapian::DB_CREATE_OR_OPEN); Xapian::TermGenerator indexer; Xapian::Stem

David — this isn't the behaviour I see what QueryParser alone, unless you're driving it in a way I don't expect. In python: >>> import xapian >>> qp = xapian.QueryParser() >>> qp.add_prefix('subject', 'S') >>> str(qp.parse_query('subject:"and"', qp.FLAG_DEFAULT|qp.FLAG_BOOLEAN_ANY_CASE)) 'Query(Sand at 1)'

Running notmuch from git on Debian testing[1] with the mail and database sitting on a ZFS filesystem, adding mail to a new database: > agrajag-testing ~/s/notmuch % ./notmuch new > Found 605510 total files (that's not much mail). > add_file: A Xapian exception occurred36m 37s remaining). > A Xapian exception occurred adding message: Unexpected end of posting list for

Hi guys I'm trying to figure out how I can use probabilistic searching on a given field within a document; I've written to the list about this before, but haven't quite figured out what's required and, following a little research, I think I understand what I need to do but I'd like a clarification on this. o We have a database of a number of documents, with fields: title,

Hi guys I've just had a thought about something we do with our search on ReportBuyer.com: we cater for both American and British English in our searches and we have had plans for a while now to implement something that allows users to find 'colour' and 'color', 'tap' and 'faucet' by doing some clever programming. Looking at the Xapian docs, though, it appears

Javier Garcia <javiertury at gmail.com> writes: > I've applied the path to notmuch 0.26.1 without success. > > $ rm -rf ~/.mail/.notmuch > $ LD_LIBRARY_PATH=/hidden-path/notmuch-0.26.1/lib/:$LD_LIBRARY_PATH > ./notmuch new >    Found 20065 total files (that's not much mail). >    Processed 20065 total files in 58s (341 files/sec.). >    Added 19605 new

Matt <mattator at gmail.com> writes: > thanks didn't know about xapian-check ! > the output > === > docdata: > blocksize=8K items=70 firstunused=3 revision=421 levels=0 root=2 > B-tree checked okay > docdata table structure checked OK > > termlist: > blocksize=8K items=186136 firstunused=62058 revision=421 levels=2 root=12260 > B-tree checked okay >

Mueen Nawaz <mueen at nawaz.org> writes: > After a lot of poking around, I figured out the problem, and this may be > of interest to the developers (although not sure if it is a xapian issue > or a notmuch issue). > > Here's why it would freeze: > > I have a post-new hook that runs a Python script. Depending on whether > the new email it is processing matches a