thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.29.2 2019-05-25T10:21:21Z 2019-05-25T10:21:21Z David Bremner david@tethera.net 2019-02-18T13:08:48Z urn:sha1:9dedb23b47961047d75ef08210481018042d0baf It's a bit odd that the primary documentation is in notmuch-config, but it is consistent with the "query:" prefix. 2019-04-17T11:48:16Z David Bremner david@tethera.net 2019-03-19T00:39:21Z urn:sha1:319dd95ebbd841320e269d34e67a824876f8426a The new `body:` field (in Xapian terms) or prefix (in slightly sloppier notmuch) terms allows matching terms that occur only in the body. Unprefixed query terms should continue to match anywhere (header or body) in the message. This follows a suggestion of Olly Betts to use the facility (since Xapian 1.0.4) to add the same field with multiple prefixes. The double indexing of previous versions is thus replaced with a query time expension of unprefixed query terms to the various prefixed equivalent. Reindexing will be needed for 'body:' searches to work correctly; otherwise they will also match messages where the term occur in headers (demonstrated by the new tests in T530-upgrade.sh) 2018-06-25T00:59:37Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2018-06-19T22:36:16Z urn:sha1:fd3c93650d976f630ba0a60341a1a695422e4969 Many of the manpages didn't treat literal text as literal text. I've tried to normalize some of the restructured text to make it a bit more regular. several of the synopsis lines are still untouched by this cleanup, but i'm not sure what the right way to represent those is in .rst, actually. In particular find that if i rebuild the manpages, sometimes i end up with some of the synopsis lines showing – (U+2013 EN DASH) where they should have -- (2 × U+002D HYPHEN-MINUS) in the generated nroff output, though i have not tracked down the source of this error yet. 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:07:20Z Matthew Lear matt@bubblegen.co.uk 2018-02-06T21:52:01Z urn:sha1:0cbe982bfd4516ee441ca5bbdd858616e54cc141 Need to be clearer about specifying time ranges using timestamps. Legacy syntax which predates the date prefix is still supported, but timestamps used in conjunction with the date prefix require additional syntax. 2017-12-31T13:06:11Z Jani Nikula jani@nikula.org 2017-12-30T17:16:11Z urn:sha1:e5e252de5560fee386bd46f8f279c800b953c667 Make all parameter descriptions etc. use reStructuredText definition lists with uniform style and indentation. Remove redundant indentation from around the lists. Remove blank lines between term lines and definition blocks. Use four spaces for indentation. This is almost completely whitespace and paragraph reflow changes. 2017-12-15T01:41:39Z Jani Nikula jani@nikula.org 2017-11-02T20:01:17Z urn:sha1:89f651a40374d07750528f45d555ce821c049c80 Having first a list of prefixes followed by detailed descriptions was viable when we didn't have all that many prefixes. Now, arranging the prefix descriptions in a definition list makes more sense. While at it, include all the supported prefix forms, especially some missing regex ones. 2017-12-08T12:08:47Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-12-08T06:24:01Z urn:sha1:29648a137c5807135ab168917b4a51d5e19e51c2 If you're going to store the cleartext index of an encrypted message, in most situations you might just as well store the session key. Doing this storage has efficiency and recoverability advantages. Combined with a schedule of regular OpenPGP subkey rotation and destruction, this can also offer security benefits, like "deletable e-mail", which is the store-and-forward analog to "forward secrecy". But wait, i hear you saying, i have a special need to store cleartext indexes but it's really bad for me to store session keys! Maybe (let's imagine) i get lots of e-mails with incriminating photos attached, and i want to be able to search for them by the text in the e-mail, but i don't want someone with access to the index to be actually able to see the photos themselves. Fret not, the next patch in this series will support your wacky uncommon use case. 2017-12-08T12:08:46Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-12-08T06:23:56Z urn:sha1:f845fb2a51f87dfa60388d65ac481ba21556bb78 The stashed session keys are stored internally as notmuch properties. So a user or developer who is reading about those properties might want to understand how they fit into the bigger picture. Note here that decrypting with a stored session key no longer needs -decrypt for "notmuch show" and "notmuch reply".