thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.27 2018-05-26T14:30:32Z 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. 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-02T01:17:47Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-06-04T12:32:34Z urn:sha1:5b93fa6e70c905e3c5f2a8109683db29ccfd5bcf This new function asks the database to reindex a given message. The parameter `indexopts` is currently ignored, but is intended to provide an extensible API to support e.g. changing the encryption or filtering status (e.g. whether and how certain non-plaintext parts are indexed). 2017-08-02T01:17:47Z David Bremner david@tethera.net 2017-06-04T12:32:33Z urn:sha1:34d77539925f8e743830a2c8df0a079956ae8be3 Testing will be provided via use in notmuch_message_reindex 2017-08-02T01:17:47Z David Bremner david@tethera.net 2017-06-04T12:32:30Z urn:sha1:8a8e2b11c208050aa1d719ec0933f58d51628fdd This operation is relatively inexpensive, as the needed metadata is already computed by our lazy metadata fetching. The goal is to support better UI for messages with multipile files. 2017-08-02T01:17:47Z David Bremner david@tethera.net 2017-06-04T12:32:27Z urn:sha1:4fdabd636e1b0417bb40c71bdce64e18f0f347e2 This function is large and hard to understand and modify. Start to break it down into meaningful pieces. 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.