thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.32.3 2021-05-22T12:08:02Z 2021-05-22T12:08:02Z David Bremner david@tethera.net 2021-05-15T18:40:22Z urn:sha1:3f4de98e7c8c70f9a86a4f899147126f79907bd9 This prevents the message document getting multiple thread-id terms when there are multiple files with the same message-id. This change shifts some thread ids, requiring adjustments to other tests. 2021-04-18T13:02:20Z David Bremner david@tethera.net 2021-03-20T13:10:52Z urn:sha1:084e60d54a752d9c26263e7540f8687b747203f9 Ignoring this return value seems like a bad idea in general, and in particular it has been hiding one or more bugs related to handling long directory names. 2020-07-28T11:47:58Z David Bremner david@tethera.net 2020-07-26T23:31:36Z urn:sha1:a09293793f43b93b7008dd361b192199ad528fca static_cast is a bit tricky to understand and error prone, so add a second pointer to (potentially the same) Xapian database object that we know has the right subclass. 2020-07-18T14:03:28Z David Bremner david@tethera.net 2020-07-11T18:30:06Z urn:sha1:a4776faa9b85159d9551617f0a61505cf5d16a5a As a side effect, we revert the switch from notmuch_bool_t to bool here. This is because those two types are not actually compatible when passing by reference. 2019-06-14T10:41:27Z uncrustify david@tethera.net 2019-06-13T10:55:35Z urn:sha1:2b62ca2e3b786beca8d89fa737bda0b49faa638d This is the result of running $ uncrustify --replace --config ../devel/uncrustify.cfg *.c *.h *.cc in the lib directory 2018-09-06T11:07:13Z David Bremner david@tethera.net 2018-08-30T11:29:15Z urn:sha1:87934c432c4bee9df09f268a3f05933c59c2caf1 As reported by Sean Whitton, there are mailers (in particular the Debian Bug Tracking System) that have sensible In-Reply-To headers, but un-useful-for-notmuch References (in particular with the BTS, the oldest reference is last). I looked at a sample of about 200K messages, and only about 0.5% these had something other than a single message-id in In-Reply-To. On this basis, if we see a single message-id in In-Reply-To, consider that as authoritative. 2017-10-21T22:53:19Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-10-21T02:25:41Z urn:sha1:4dfcc8c9b2e1dbb965f69283dca50c7581c88050 If we see index options that ask us to decrypt when indexing a message, and we encounter an encrypted part, we'll try to descend into it. If we can decrypt, we add the property index.decryption=success. If we can't decrypt (or recognize the encrypted type of mail), we add the property index.decryption=failure. Note that a single message may have both values of the "index.decryption" property: "success" and "failure". For example, consider a message that includes multiple layers of encryption. If we manage to decrypt the outer layer ("index.decryption=success"), but fail on the inner layer ("index.decryption=failure"). Because of the property name, this will be automatically cleared (and possibly re-set) during re-indexing. This means it will subsequently correspond to the actual semantics of the stored index. 2017-10-21T22:52:47Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-10-21T02:25:38Z urn:sha1:20ff9de24de47e591dd45e7dde0ac10948d6cbf6 This is currently mostly a wrapper around _notmuch_crypto_t that keeps its internals private and doesn't expose any of the GMime API. However, non-crypto indexing options might also be added later (e.g. filters or other transformations). 2017-10-10T01:27:16Z Jani Nikula jani@nikula.org 2017-10-07T08:44:05Z urn:sha1:008a5e92eb157e2bb8622cb2fbf644deba5ba4b4 C99 stdbool turned 18 this year. There really is no reason to use our own, except in the library interface for backward compatibility. Convert the lib internally to stdbool. 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.