thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=debian%2F0.27-3 2018-05-26T15:31:03Z 2018-05-26T15:31:03Z David Bremner david@tethera.net 2018-05-21T20:08:56Z urn:sha1:b50fb1b642be5f418db56f00f4518b1d3b2c83eb This is mainly to improve discoverability. It seems that doing variable cross-references is not easy without using some sphinx extension/customization. 2018-05-26T15:29:35Z David Bremner david@tethera.net 2018-05-21T20:08:55Z urn:sha1:7a58c1c44bfc31aea4b4b8698c2941365f3e65b6 2018-05-26T15:28:18Z David Bremner david@tethera.net 2018-05-21T20:08:54Z urn:sha1:eb6fb36d6337d11788ccd632719917445c7be467 This is pretty minimal, but will hopefully inspire others to contribute more complete documentation. If nothing else, it points out '?'. 2018-05-26T15:26:13Z David Bremner david@tethera.net 2018-05-21T20:08:51Z urn:sha1:7a6d4a0852664483bbba702cf3b030448b079e2c All of the man pages are installed as info pages, plus the (unfinished) notmuch-emacs manual 2018-05-26T14:43:30Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2018-05-11T06:57:59Z urn:sha1:aa605f7e8a4c5e046503d61fdb953721c32f9d3a Add fancy new feature, which makes "notmuch show" capable of actually indexing messages that it just decrypted. This enables a workflow where messages can come in in the background and be indexed using "--decrypt=auto". But when showing an encrypted message for the first time, it gets automatically indexed. This is something of a departure for "notmuch show" -- in particular, because it requires read/write access to the database. However, this might be a common use case -- people get mail delivered and indexed in the background, but only want access to their secret key to happen when they're directly interacting with notmuch itself. In such a scenario, they couldn't search newly-delivered, encrypted messages, but they could search for them once they've read them. Documentation of this new feature also uses a table form, similar to that found in the description of index.decrypt in notmuch-config(1). A notmuch UI that wants to facilitate this workflow while also offering an interactive search interface might instead make use of these additional commands while the user is at the console: Count received encrypted messages (if > 0, there are some things we haven't yet tried to index, and therefore can't yet search): notmuch count tag:encrypted and \ not property:index.decryption=success and \ not property:index.decryption=failure Reindex those messages: notmuch reindex --try-decrypt=true tag:encrypted and \ not property:index.decryption=success and \ not property:index.decryption=failure 2018-05-22T16:31:33Z David Bremner david@tethera.net 2018-04-29T23:19:43Z urn:sha1:8a1eeecdfe83a5ca0a923e5d1e31bff076e406ce 2018-05-09T14:31:57Z David Bremner david@tethera.net 2018-05-08T15:12:55Z urn:sha1:a07b28a488cd5d8f3d9dcf77401cc43ce6473138 For some reason the searched tag did not match the displayed results. 2018-05-07T11:42:53Z David Bremner david@tethera.net 2018-05-05T15:59:28Z urn:sha1:f2e6f76a046492650713c1c3f1f1a19f49de59ea Mention both performance and quoting issues. 2018-04-25T02:08:10Z David Bremner david@tethera.net 2018-04-07T22:10:51Z urn:sha1:20ba0b7dfae2111f76d71c8d695265014c2ef7c5 I think we've diverged enough from the Xapian query parser that we can't rely on that syntax description [1]. As far as I can tell, [1] also only discusses quotes in the context of phrases. [1]: https://xapian.org/docs/queryparser.html 2018-03-24T23:08:27Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2018-02-21T17:50:27Z urn:sha1:f6430bc06d479fdf0b180231d3a3b5fb67bbb8e0 Currently, notmuch has the levers needed to set coherent crypto policy around how cleartext is indexed, which also has an impact on how messages are rendered. But we don't have a lot of documentation about how to do sensible things. This is an initial attempt to address that. The first example shows a way to selectively index specific messages. The next two examples are about aligning the existing database with crypto indexing policy The default crypto policy is to not index cleartext, and to only decrypt messages on display when explicitly requested. The other sensible crypto policy is to index cleartext while stashing session keys. messages indexed in this way will be searchable, and will be decrypted on display automatically unless the user explicitly asks for it to *not* be decrypted. The policy for indexing *new* messages is stored in the database as the config variable index.decrypt. But setting policy for new messages doesn't retroactively affect already indexed messages. This patch attempts to document ways that someone can efficiently align their pre-existing database with their new policy. I'm not sure this is the right place to document these examples, but i do want them to be user-facing and relatively easy to find. I'm happy to entertain suggestions for where else we should put them.