thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=debian%2F0.28.3-1 2018-09-06T11:07:13Z 2018-09-06T11:07:13Z David Bremner david@tethera.net 2018-08-30T11:29:08Z urn:sha1:0a7181dd163babefaefa9988ed51dc66c892eb3e This will be used in reparenting messages without useful in-reply-to, but with useful references 2018-09-06T11:07:12Z David Bremner david@tethera.net 2018-08-30T11:29:05Z urn:sha1:d0b844b358f7bb7bc7c6f152223577efcebfc89b The plan is to use these in resolving threads. 2018-09-06T11:07:12Z David Bremner david@tethera.net 2018-08-30T11:29:04Z urn:sha1:9b568e73e1afc211306d18dac3d27df4a07a0fdd For non-root messages, this should not should anything currently, as the messages are already added in date order. In the future we will add some non-root messages in a second pass out of order and the sorting will be useful. It does fix the order of multiple root-messages (although it is overkill for that). 2018-05-26T14:32:01Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2018-05-11T06:57:54Z urn:sha1:6a9f26b4a04e20529203938a99658516876c67f3 This is technically an API change, but it is not an ABI change, and it's merely a statement that limits what the library can do. This is in parallel to notmuch_query_get_database(), which also takes a const pointer. 2018-05-26T14:30:32Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2018-05-11T06:57:52Z urn:sha1:9088db76d89264b733f6b45e776d8952da237921 We've had _notmuch_message_database() internally for a while, and it's useful. It turns out to be useful on the other side of the library interface as well (i'll use it later in this series for "notmuch show"), so we expose it publicly now. 2018-05-07T11:42:53Z David Bremner david@tethera.net 2018-01-28T02:50:42Z urn:sha1:f0131af6c59704e29d58eb74ed5e4bc298455272 The observation is that we are only using the messages to get there thread_id, which is kindof a pessimal access pattern for the current notmuch_message_get_thread_id 2017-12-08T12:08:47Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-12-08T06:24:00Z urn:sha1:6a9626a2fdddf6115bcf97982fd10053bf48e942 There are some situations where the user wants to get rid of the cleartext index of a message. For example, if they're indexing encrypted messages normally, but suddenly they run across a message that they really don't want any trace of in their index. In that case, the natural thing to do is: notmuch reindex --decrypt=false id:whatever@example.biz But of course, clearing the cleartext index without clearing the stashed session key is just silly. So we do the expected thing and also destroy any stashed session keys while we're destroying the index of the cleartext. Note that stashed session keys are stored in the xapian database, but xapian does not currently allow safe deletion (see https://trac.xapian.org/ticket/742). As a workaround, after removing session keys and cleartext material from the database, the user probably should do something like "notmuch compact" to try to purge whatever recoverable data is left in the xapian freelist. This problem really needs to be addressed within xapian, though, if we want it fixed right. 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:53:08Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-10-21T02:25:40Z urn:sha1:0bb05ff693737c5b91d6a64f6209984a6c418c46 This allows us to create new properties that will be automatically set during indexing, and cleared during re-indexing, just by choice of property name. 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.