thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.32.1 2020-12-23T13:25:01Z 2020-12-23T13:25:01Z David Bremner david@tethera.net 2020-08-08T14:16:45Z urn:sha1:22d9094300751ea6f995fcb5f04194b06f77db3a Reduce the size of database.cc, and prepare for extending the database opening API 2020-12-23T13:21:17Z David Bremner david@tethera.net 2020-08-08T14:16:44Z urn:sha1:3b4097824159c6fdebb8a88b5447beb9a6226ea3 Reduce the size of database.cc, and limit the scope of prefix_table, make sure it's accessed via a well-defined internal API. 2020-12-23T13:06:34Z David Bremner david@tethera.net 2020-08-08T14:16:43Z urn:sha1:e34e2a68b62b50cc40e695d1a2690a7de382bba6 database.cc is uncomfortably large, and some of the static data structures do not need to be shared as much as they are. This is a somewhat small piece to factor out, but it will turn out to be helpful to further refactoring. 2020-08-10T00:14:36Z Jonas Bernoulli jonas@bernoul.li 2020-08-08T11:49:49Z urn:sha1:c4541353765dec837c1c2f912b1bf6661827429c Use `makefile-gmake-mode' instead of `makefile-mode' because the former also highlights ifdef et al. while the latter does not. "./Makefile.global" and one "Makefile.local" failed to specify any major mode at all but doing so is necessary because Emacs does not automatically figure out that these are Makefiles (of any flavor). 2018-05-07T11:42:53Z David Bremner david@tethera.net 2017-12-26T01:03:05Z urn:sha1:5ad39ebf75eb85263e4b64f21e07ec02194f9573 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 2017-12-28T14:05:55Z David Bremner david@tethera.net 2017-12-28T14:05:55Z urn:sha1:b09025bce2b795f3d49b92cb3dac437b92831321 This reverts commit 4f5bbaf7e2cecfe5022ba4b28915cccfb7ccb12d. 2017-12-26T00:40:28Z David Bremner david@tethera.net 2017-08-20T21:32:40Z urn:sha1:4f5bbaf7e2cecfe5022ba4b28915cccfb7ccb12d 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 2017-09-13T11:48:17Z Jani Nikula jani@nikula.org 2017-09-10T11:56:16Z urn:sha1:eb29e26a99389c0ec8504e746fad01fdbeafff7f Broken, again, by yours truly in bc11759dd1fd ("build: switch to hiding libnotmuch symbols by default"). Reference notmuch.sym via $(srctree). 2017-08-23T10:55:12Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-08-17T23:14:26Z urn:sha1:eb232ee0aba8f031fe4f0cb509682a321d85e06e 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. 2017-08-02T01:17:47Z David Bremner david@tethera.net 2017-06-04T12:32:26Z urn:sha1:2f94b3090c03bb56b43c4adfb94f7eeb28a6bf18 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.