[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#21462: 25.0.50; Gnus thread gathering and sorting inverted
From: |
Michael Welsh Duggan |
Subject: |
bug#21462: 25.0.50; Gnus thread gathering and sorting inverted |
Date: |
Mon, 08 Feb 2016 12:08:45 -0500 |
User-agent: |
Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) |
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)