notmuch/test/T510-thread-replies.sh, branch master

test: source $NOTMUCH_SRCDIR/test/test-lib-emacs.sh

2021-06-03T12:29:27Z

Sourcing test-lib.sh will cd to TMP_DIRECTORY, so relative path in $0 will not work in previous version . $(dirname "$0")/test-lib-emacs.sh Now individual test scripts -- e.g. ./test/T310-emacs.sh will work.

test: split emacs functionality to its own file

2021-05-17T10:29:04Z

This way it's easier to identify the tests that do require emacs stuff. Signed-off-by: Felipe Contreras

test: clean up some extra whitespace.

2021-03-12T11:19:14Z

The extra space is mainly just untidy.

cli/show: emit new whole-message crypto status output

2019-05-26T11:20:23Z

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

lib: change parent strategy to use In-Reply-To if it looks sane

2018-09-06T11:07:13Z

As reported by Sean Whitton, there are mailers (in particular the Debian Bug Tracking System) that have sensible In-Reply-To headers, but un-useful-for-notmuch References (in particular with the BTS, the oldest reference is last). I looked at a sample of about 200K messages, and only about 0.5% these had something other than a single message-id in In-Reply-To. On this basis, if we see a single message-id in In-Reply-To, consider that as authoritative.

test/thread-replies: mangle In-Reply-To's

2018-09-06T11:07:13Z

In a future commit, we will start trusting In-Reply-To's when they look sane (i.e. a single message-id). Modify these tests so they will keep passing (i.e. keep choosing References) when that happens.

test: add known broken test for good In-Reply-To / bad References

2018-09-06T11:07:13Z

The current scheme of choosing the replyto (i.e. the default parent for threading purposes) does not work well for mailers that put the oldest Reference last.

lib/thread: change _resolve_thread_relationships to use depths

2018-09-06T11:07:13Z

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.

lib/thread: initial use of references as for fallback parenting

2018-09-06T11:07:13Z

This is mainly to lay out the structure of the final code. The problem isn't really solved yet, although some very simple cases are better (hence the fixed test). We need two passes through the messages because we need to be careful not to re-parent too many messages and end up without any toplevel messages.

lib/thread: sort sibling messages by date

2018-09-06T11:07:12Z

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).