>> I haven't tracked through all the logic of the existing algorithm for >> this case. But I don't like hearing that notmuch constructs different >> threads for the same messages presented in different orders. This sounds >> like a bug separate from what we've discussed above.
I think I have now found this bug and it is separate from the malformed In-Reply-To problems. The problem is that when we merge threads we update all the thread-ids of documents in the loser thread. But we don't (if I understand the code correctly) update dangling "metadata" references to threads which don't (yet) have any documents. To make this explicit consider the 2 messages 17,18 in the set. Message 17 has id <[email protected]> and has no references/in-reply-to so has no parents. Message 18 has a reference to <[email protected]> and an in-reply-to to <[email protected]> and <[email protected]> If you add 17 first then it gets thread-id 1 and then when you add 18 message 18 gets thread-id 2 as does the dangling link to the "unseen" message [email protected], and then message 17 is moved to thread-id 2. However, if you add 18 first then it gets thread-id 1 and the dangling link gets id 1. When 17 is added it gets thread-id 2, message 18 gets thread-id updated to 2 *but* the dangling link to [email protected] does not get updated so stays thread-id 1. In particular when 52 comes along with its link to [email protected] then: In the first case it gets put in thread-id 3 and the other two messages get moved into thread 3. In the second case, message 52 gets put in thread 3 and thread 1 (the dangling link) gets moved into thread 3 leaving thread 2 (containing messages 17 and 18) untouched. Best wishes Mark _______________________________________________ notmuch mailing list [email protected] http://notmuchmail.org/mailman/listinfo/notmuch
