thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.38_rc2 2021-05-22T12:34:55Z 2021-05-22T12:34:55Z David Bremner david@tethera.net 2021-05-22T12:34:55Z urn:sha1:702635d5f61729b5d0453f73d8eaa4bc6eb50ed4 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-05-14T09:38:19Z David Bremner david@tethera.net 2021-05-11T11:08:32Z urn:sha1:929386fad90eed7dad8b32f457020c57a786d288 Work towards the goal of concurrent access to different Xapian databases from the same process. 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).