thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.28.3 2018-09-06T11:07:13Z 2018-09-06T11:07:13Z David Bremner david@tethera.net 2018-08-30T11:29:14Z urn:sha1:b31e44c678bf3bfe81bcc5f159e627551f12700f The idea is that if a message-id parses with this function, the MUA generating it was probably sane, and in particular it's probably safe to use the result as a parent from In-Reply-to. 2018-09-06T11:07:13Z David Bremner david@tethera.net 2018-08-30T11:29:10Z urn:sha1:46dce33abc82ea6ebd3be2e0887506af4185c739 We (finally) implement the XXX comment. It requires a bit of care not to reparent all of the possible toplevel messages. _notmuch_messages_has_next is not ready to be a public function yet, since it punts on the mset case. We know in the one case it is called, the notmuch_messages_t is just a regular list / iterator. 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:13Z David Bremner david@tethera.net 2018-09-03T21:02:25Z urn:sha1:dc3cc18bf0c649dfdb280a7afbb3b6039101f281 There is no public notmuch_message_list_t public interface, so to this is added to the private API. We use it immediately in thread.cc; future commits will use it further. 2018-09-06T11:07:12Z David Bremner david@tethera.net 2018-09-03T14:00:26Z urn:sha1:040fd630bf74eb8be75633bf3cbdb0c38d0f16f2 This is analogous to DEBUG_DATABASE_SANITY, and is intended to help debugging and to help users submit bug reports. 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: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-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.