bug#21462: 25.0.50; Gnus thread gathering and sorting inverted

[Michael Welsh Duggan <mwd@cert.org>]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Michael Welsh Duggan <mwd@md5i.com> writes:
>
>> 1) gnus-make-threads -> gathers articles into threads by ref
>> 2) gnus-cut-threads  -> removes "uninteresting" articles from the
>>    threads
>> 3) gnus-sort-threads -> sorts the threads (with respect to each other thread)
>> 4) gnus-summary-thread-gathering-function -> gathers threads with
>>    similar characteristics (subject, reference) into a single thread
>> 5) gnus-sort-gathered-threads -> sorts the articles within each thread
>>
>> My argument is that steps 3 and 4 are backwards.  Step 4 is the place
>> where the final thread groupings are decided, and sorting these threads
>> with respect to each other should happen afterward.
>
> Yes, but can't you just sort the gathered threads in the way you would
> have wanted to have them sorted if they had been sorted before
> gathering?  I think I vaguely think that should kinda work...

If I understand correctly, that would (in my case) require writing my
own version of gnus-gather-threads-by-subject.  All I can say to that
is, ugh.  If this sorting and gathering were done in what I consider to
be the more logical order, I have to write a two line function to do
what I want.  Instead I would have to mimic most of the functionality of
gnus-gather-threads-by-subject with the added restriction that I want to
maintain thread order by the latest gathered thread.  Complicated and
ugly.  Not that I wouldn't do it, if needed.  Is there a good reason for
step 3 and 4 above to be in the given order instead of the reverse?

-- 
Michael Welsh Duggan
(mwd@cert.org)