thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=nmweb 2023-07-21T09:58:16Z 2023-07-21T09:58:16Z David Bremner david@tethera.net 2023-04-09T14:26:23Z urn:sha1:dfa43a19218ed46f677034ab7bf8b8907a327935 When running the test suite without building first, it is desirable to have the tests consider these variables being undefined as equivalent to the feature not being present, and in particular for the tests not to generate errors. 2022-07-30T11:45:15Z David Bremner david@tethera.net 2022-07-01T21:45:47Z urn:sha1:24decfc1dd294b7546da53890f1c4d16105cc8d6 We want the reply used to match that shown e.g. in the emacs interface. As a first step provide that functionality on the command line. Schema does not need updating as the duplicate key was already present (with a constant value of 1). 2022-07-05T10:01:39Z David Bremner david@tethera.net 2022-07-01T21:45:40Z urn:sha1:5f6645bd2a07542902fe9b39b986fdde69a0ebcf This makes the tests more robust against changing output formats, by allowing us to centralize fixes in the sanitization function. It is not appropriate for all cases, in particular it is unneeded when using test_json_nodes, and unhelpful when testing filenames. 2021-09-05T00:07:19Z David Bremner david@tethera.net 2021-08-24T15:17:43Z urn:sha1:2944d5913319056dfec5c23065932fd1c87a96f6 The change in each case is to call notmuch_query_create_with_syntax, relying on the already inherited shared options. As a bonus we get improved error handling from the new query creation API. The remaining subcommand is 'tag', which is a bit trickier. 2021-08-30T01:10:08Z Hannu Hartikainen hannu@hrtk.in 2021-07-02T09:13:09Z urn:sha1:717e3dcdc3e55d72c8e4a1948708c34170dbf926 When using notmuch-reply and guessing the From: address from Delivered-To headers, I had the wrong address chosen today. This was because the messages from the notmuch list contain these headers in this order: Delivered-To: hannu.hartikainen@gmail.com ... Delivered-To: hannu@hrtk.in In my .notmuch-config I have the following configuration: primary_email=hannu@hrtk.in other_email=hannu.hartikainen@gmail.com;... Before this change, notmuch-reply would guess From: @gmail.com because that is the first Delivered-To header present. After the change, the primary address is chosen as I would expect. 2021-08-30T01:07:59Z Hannu Hartikainen hannu@hrtk.in 2021-07-02T09:13:08Z urn:sha1:8c0bebedc5edbff5ddc46b66da1177ec18f48c69 Add a known broken subtest for guessing From: correctly when there are multiple Delivered-To: headers. The address configured as primary_email should get picked. 2019-05-26T11:20:23Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2019-05-25T18:04:06Z urn:sha1:4cb789aa090fb6ba3c7897584ecbcc0a547b2f81 This allows MUAs that don't want to think about per-mime-part cryptographic status to have a simple high-level overview of the message's cryptographic state. Sensibly structured encrypted and/or signed messages will work fine with this. The only requirement for the simplest encryption + signing is that the message have all of its encryption and signing protection (the "cryptographic envelope") in a contiguous set of MIME layers at the very outside of the message itself. This is because messages with some subparts signed or encrypted, but with other subparts with no cryptographic protection is very difficult to reason about, and even harder for the user to make sense of or work with. For further characterization of the Cryptographic Envelope and some of the usability tradeoffs, see here: https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html#cryptographic-envelope 2018-12-07T12:03:50Z David Edmondson dme@dme.org 2018-10-01T16:50:47Z urn:sha1:576cff7654a4c3e0c94498977ce7b28ce8f00251 When generating a reply message, if the user was the originator and only recipient of the original message, include the user as a recipient of the reply. 2017-10-20T22:52:49Z Jani Nikula jani@nikula.org 2017-09-25T20:38:19Z urn:sha1:a863de1e43ee34f6f5794a2759fdceb287e851aa Don't assume the tests are always run from within the source tree. 2017-07-15T00:23:52Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-07-14T20:14:23Z urn:sha1:8492298a613e8e666d0f3054dadcb98b72a65ae4 The reply-to munging code might behave differently whether there's an exact match on the strings or not, or whether the string is a raw addr-spec instead of an name-addr. These tests cover those variations (i also had to tweak json output further below when this new test was added).