notmuch/lib/Makefile.local, branch 0.26.1

Revert "lib: add thread subqueries."

2017-12-28T14:05:55Z

This reverts commit 4f5bbaf7e2cecfe5022ba4b28915cccfb7ccb12d.

lib: add thread subqueries.

2017-12-26T00:40:28Z

This change allows queries of the form thread:{from:me} and thread:{from:jian} and not thread:{from:dave} This is still somewhat brute-force, but it's a big improvement over both the shell script solution and the previous proposal [1], because it does not build the whole thread structure just generate a query. A further potential optimization is to replace the calls to notmuch with more specialized Xapian code; in particular it's not likely that reading all of the message metadata is a win here. [1]: id:20170820213240.20526-1-david@tethera.net

build: fix out-of-tree builds, again

2017-09-13T11:48:17Z

Broken, again, by yours truly in bc11759dd1fd ("build: switch to hiding libnotmuch symbols by default"). Reference notmuch.sym via $(srctree).

reindex: drop notmuch_param_t, use notmuch_indexopts_t instead

2017-08-23T10:55:12Z

There are at least three places in notmuch that can trigger an indexing action: * notmuch new * notmuch insert * notmuch reindex I have plans to add some indexing options (e.g. indexing the cleartext of encrypted parts, external filters, automated property injection) that should properly be available in all places where indexing happens. I also want those indexing options to be exposed by (and constrained by) the libnotmuch C API. This isn't yet an API break because we've never made a release with notmuch_param_t. These indexing options are relevant in the listed places (and in the libnotmuch analogues), but they aren't relevant in the other kinds of functionality that notmuch offers (e.g. dump/restore, tagging, search, show, reply). So i think a generic "param" object isn't well-suited for this case. In particular: * a param object sounds like it could contain parameters for some other (non-indexing) operation. This sounds confusing -- why would i pass non-indexing parameters to a function that only does indexing? * bremner suggests online a generic param object would actually be passed as a list of param objects, argv-style. In this case (at least in the obvious argv implementation), the params might be some sort of generic string. This introduces a problem where the API of the library doesn't grow as new options are added, which means that when code outside the library tries to use a feature, it first has to test for it, and have code to handle it not being available. The indexopts approach proposed here instead makes it clear at compile time and at dynamic link time that there is an explicit dependency on that feature, which allows automated tools to keep track of what's needed and keeps the actual code simple. My proposal adds the notmuch_indexopts_t as an opaque struct, so that we can extend the list of options without causing ABI breakage. The cost of this proposal appears to be that the "boilerplate" API increases a little bit, with a generic constructor and destructor function for the indexopts struct. More patches will follow that make use of this indexopts approach.

lib: factor out message-id parsing to separate file.

2017-08-02T01:17:47Z

This is really pure C string parsing, and doesn't need to be mixed in with the Xapian/C++ layer. Although not strictly necessary, it also makes it a bit more natural to call _parse_message_id from multiple compilation units.

lib: isolate n_d_add_message and helper functions into own file

2017-08-02T01:17:47Z

'database.cc' is becoming a monster, and it's hard to follow what the various static functions are used for. It turns out that about 1/3 of this file notmuch_database_add_message and helper functions not used by any other function. This commit isolates this code into it's own file. Some side effects of this refactoring: - find_doc_ids becomes the non-static (but still private) _notmuch_database_find_doc_ids - a few instances of 'string' have 'std::' prepended, avoiding the need for 'using namespace std;' in the new file.

build: switch to hiding libnotmuch symbols by default

2017-05-12T10:17:18Z

The dynamic generation of the linker version script for libnotmuch exports has grown rather complicated. Reverse the visibility control by hiding symbols by default using -fvisibility=hidden, and explicitly exporting symbols in notmuch.h using #pragma GCC visibility. (We could also use __attribute__ ((visibility ("default"))) for each exported function, but the pragma is more convenient.) The above is not quite enough alone, as it would "leak" a number of weak symbols from Xapian and C++ standard library. Combine it with a small static version script that filters out everything except the notmuch_* symbols that we explicitly exposed, and the C++ RTTI typeinfo symbols for exception handling. Finally, as the symbol hiding test can no longer look at the generated symbol table, switch the test to parse the functions from notmuch.h.

rename libutil.a to libnotmuch_util.a

2017-03-19T00:37:43Z

Apparently some systems (MacOS?) have a system library called libutil and the name conflict causes problems. Since this library is quite notmuch specific, rename it to something less generic.

lib: regexp matching in 'subject' and 'from'

2017-03-03T21:46:48Z

the idea is that you can run % notmuch search subject:// % notmuch search from:// or % notmuch search subject:"your usual phrase search" % notmuch search from:"usual phrase search" This feature is only available with recent Xapian, specifically support for field processors is needed. It should work with bindings, since it extends the query parser. This is easy to extend for other value slots, but currently the only value slots are date, message_id, from, subject, and last_mod. Date is already searchable; message_id is left for a followup commit. This was originally written by Austin Clements, and ported to Xapian field processors (from Austin's custom query parser) by yours truly.

lib: use glib for sha1 digests instead of embedding libsha1

2017-01-08T14:50:38Z

We already depend on glib both directly and indirectly (via gmime). We might as well make use of its facilities. Drop the embedded libsha1 and use glib for sha1 digests.