Sort threads according to their newest message not wrt the first message in mu4e headers view. #164
Comments
|
mu4e/mu do understand threads now, but not to the extent that you could implement sorting by some specific message within the thread... |
|
This is literally my only complaint about mu4e these days. Is it something that could be added by hacking elisp, or does it require writing C? |
|
I know money doesn't necessarily help get features written, but I'd be willing to put some money towards this on bountysource.com if it would help. Let me know if it's something worth considering and I can set up a bounty. |
|
I would happly join in and contribute something. |
|
Me, too. |
|
can anyone confirm this feature as done? We implemented this; I'm very much interested in feedback. |
|
In my setup it seems to work properly. I haven't done any systematic testing though. Thank you very much for implementing this, @omfgroflbbq! |
|
Holy smokes; it's working. Nice job! |
|
this issue can be closed now, can't it? |
Traverse the container tree depth first and for each container find
the node in the subtree rooted at this container which comes first in
the descending sort order. Remember it as the subtree leader. Then,
while sorting siblings, compare their subtree leaders instead of the
sibling containers themselves.
IOW, make threads containing the newest message float to the top when
sorting by date in the descending order.
There is no significant performance degradation when sorting a
mailbox with ~16k messages:
$ mu find maildir:/INBOX | wc -l
16503
Current state:
$ perf stat --event=task-clock --repeat=10 -- \
mu find maildir:/INBOX -n 1 -t > /dev/null
Performance counter stats for 'mu find maildir:/INBOX -n 1 -t' (10 runs):
1231.761588 task-clock (msec) # 0.996 CPUs utilized ( +- 1.02% )
1.236209133 seconds time elapsed ( +- 1.08% )
With patch applied:
$ perf stat --event=task-clock --repeat=10 -- \
mu find maildir:/INBOX -n 1 -t > /dev/null
Performance counter stats for 'mu find maildir:/INBOX -n 1 -t' (10 runs):
1459.883316 task-clock (msec) # 0.998 CPUs utilized ( +- 0.72% )
1.462540088 seconds time elapsed ( +- 0.77% )
This implements djcb#164.
|
Apparently this is working now. Thanks! |
|
Thank you! |
|
bug seems back. no? |
|
Is it possible to take advantage of this in mu4e? I can't find any documentation on it. |
|
This is not currently implemented. |
(This topic has been discussed by Jacek Generowicz and Dirk-Jan on the mailing list. I add it here for the record.)
Mu4e sorts threads according to the date of their first message. The drawback is that new messages in old threads may not show up in the list of recent mails (mails within the
mu4e-headers-results-limit). Therefore, it's easy to miss them. Apart from checking their (threaded) inbox users have to perform additional steps to ensure that they don't miss messages. Sorting threads according to the date of their newest message is more desirable. This way new messages always show up at the top.Dirk-Jan pointed out that it may be difficult to make this work as long as the database doesn't understand threads. However, this discussion suggests that mu has in fact learned a few things about threads recently. Perhaps sorting threads according to the newest message is more feasible now?
The text was updated successfully, but these errors were encountered: