GNOME Bugzilla – Bug 243463
subsequent order of threading broken
Last modified: 2009-12-17 16:51:53 UTC
The order of sibsequent mails in a thread is broken. The order only applies to the tree roots. I have my mails sorted by date, newest on top. Replies to the same message don't inherit that order -- they are sorted by the order in the mbox file. This one is hard to track, cause normally mails getting appended to the mbox later are sent later, too. As an example: (order by date, newest on top) root mail B (02:00) root mail A (01:00) + reply (02:00) + reply (03:00) The 2 replies are in reverse order. Changing the sort order (date) have no effect. For your convenience I will attach a screenshot. To reproduce it yourself, I even will attach a mbox file copied from my IMAP server. I stripped unnecessary headers out, anonymized it. All headers that don't look faked, are the _original_ ones. Steps to reproduce the problem: - copy the mbox file to your mails and see for yourself... ;-) Expected Results: - order replies on the same level in threads just as root-nodes
Created attachment 42450 [details] screenshot
Created attachment 42451 [details] mbox
> they are sorted by the order in the mbox file. Forgot: You can verify this, when the mails are moved/copied to another folder. You can control the order by resorting the replies.
sounds like an ETree bug?
I think this is actually the request where if you sort in descending date order the children of the first item in a thread are in descending order as well (ie out of order for thread reading purposes).
related to bug 309701
Karsten, are you saying you want a thread to also be sorted newest to oldest? Would the most recent reply also now be the root node for the thread? (If so, you'd want to look at stripping of the Re:/Ant:/Sk:/etc prefix.) Which option is closer to what you want? Option 1) root mail B (02:00) root mail A (01:00) + reply (03:00) + reply (02:00) Option 2) root mail B (02:00) reply (03:00) + reply (02:00) + root mail A (01:00) I dislike both (which is why I filed bug 309701), and no other mail client does either of these, but I think the current behavior is the same as Option 1 above.
Or even Option 3) reply (03:00) + reply (02:00) + root mail A (01:00) root mail B (02:00) (Since reply at 03:00 is the most recent, that thread would be promoted.)
Michael, please read my original report carefully again. I do *not* want anything along the lines of your options 2 and 3. This simply is no threading, cause the In-Reply-To and References headers are not represented in that "tree" you outlined. I'd consider this behavior a serious bug and would instantly file a bug report about his. The root mail always has to be the root. All direct children have to be displayed as direct children of its parent. And if any child happens to be the parent for a sub-tree, start over again with this child as the rot node of the sub tree. ;) I don't get at all what this got to do with "stripping prefixes". This is not an issue, as I'm not complaining about broken MUAs -- I'm talking about threads with proper threading headers set. To make this clear: The threading is fine. This bug is not about threading itself. This bug is about the sort order inside the thread (or tree). In fact, the sort oder of the view is applied *only* to the root nodes. Those are sorted correctly. What is not sorted correctly, are the children -- they just are not sorted at all. To verify this, manually create a mbox file, like I did previously. All direct children of the same parent are not sorted according to the sort order of the view. They are added as children in the order they appear in in the mbox file. This is a pretty old bug, and I did not check this in depth for quite a long time. So I'm not sure about current behaviour. Thinking about this for a second... May this actually be current behavior? :) According to my original report and the example mentioned, your option 1 would be what I exptected, I guess -- simply applying the sort order to children inside a thread, rather than using the physical order in the mbox file (and not sorting at all).
removing old target milestone.
This report has not seen any changes or updates for more than 3 years. Also, GAL was merged into Evolution in June 2005. Actual GAL bugs are now located in the Product "Evolution", component "GAL". The external, separate GAL codebase will not receive any changes. We kindly ask you to check whether the issue you have reported here still happens in GNOME 2.26 or 2.28. If so, please update this report by adding a short comment, removing the NEEDINFO state, updating the "Version" field and moving this to the Evolution product (if you have sufficient Bugzilla rights to do so). Again thank you for reporting this bug and we are sorry it could not be handled for the version you originally used here.
Closing as per last comment. Feel free to reopen and move this to Evolution if it is still valid.