Subject: bug#53755: 27.2; C-u M-x gnus-summary-sort-by-most-recent-number / -date not ordering threads as expected

From: Kévin Le Gouguec <[email-masked]>
Date: Sat, 05 Feb 2022 15:13:04 +0100

Hey Emilia, hey Michael, hey Lars,

Emilia Blåsten <[email-masked]> writes:

> Michael Welsh Duggan <[email-masked]> 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 🙃