Hey Emilia, hey Michael, hey Lars, Emilia Blåsten writes: > Michael Welsh Duggan writes: > >> I run with the included patch. In the group for which I care about >> this, I set the following group parameter: >> >> (gnus-thread-sort-functions >> 'md5i-thread-sort-by-most-recent-date-reverse) >> >> where `md5i-thread-sort-by-most-recent-date-reverse' is defined thusly: >> >> (defun md5i-thread-sort-by-most-recent-date-reverse (h1 h2) >> (<= (gnus-thread-latest-date h1) (gnus-thread-latest-date h2))) Thanks for the patch; I've applied it, and the results are quite satisfying on my end. My gnus-thread-sort-functions are configured like so (cf. bug#42334): (setq gnus-thread-sort-functions '(gnus-thread-sort-by-number (not gnus-thread-sort-by-most-recent-date))) … which /I think/ should be equivalent to your configuration: at first glance, it seems to me like your custom sort function is equivalent to (not gnus-thread-sort-by-most-recent-date)? I'm attaching the summary buffers I get for one of my IMAP folders, with the current code, and with your patch applied. I've also tried your patch with the .mbox from bug#42334, and things also work as expected. > Since this part of the code is very old, I > do understand that you would hesitate changing it, in which case this > can be closed from my part. Now that Michael has blessed us with a patch, I guess I could live with keeping it applied locally, but I really wonder how useful the current semantics of gnus-thread-sort-by-most-recent-date are… since… threads don't end up sorted by date 🙃