Re: Problem with thread sorting

[Dan Christensen <jdc@uwo.ca>]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> This is how it's done:
>
> 	   (gnus-sort-gathered-threads
> 	    (funcall gnus-summary-thread-gathering-function
> 		     (gnus-sort-threads
> 		      (gnus-cut-threads (gnus-make-threads)))))
>
> First each thread is sorted, then they are gathered, and then the
> threads inside the gathered threads are sorted individually.
>
> You would rather that the threads be gathered first, then the threads
> are sorted (somehow), and then the threads inside the gathered threads
> would be sorted.
>
> However, I don't think that can be done.  Take the default sorting
> parameter now -- sort by root article number.  What's the root article
> number of a gathered thread?  The article number of the first thread?
> The article number of the first thread after sorting the sub-threads?
> Or what?

You are right that a somewhat arbitrary decision needs to be made here.

> So I think what it does now is reasonable.

I think the current way is also arbitrary, but is arbitrary in a way
that can't be controlled.  For example, suppose that before gathering,
the threads are sorted as

Thread 1
Thread 2 *
Thread 3
Thread 4 *
Thread 5

and that threads 2 and 4 are going to be gathered together in the next
step.  I believe that what happens now is that you end up with both in
either the position of thread 2 or thread 4, and that there are no user
settings to control this.  For sorting by root article number, it would
be equivalent to gather the threads first, and then sort them using one
of the arbitrary suggestions you make above, so there is no loss in
switching to this method.  But for sorting functions that traverse the
thread, like most-recent-date, sorting after gathering would produce
correct results.

In principle the current method doesn't really make sense, since why
would you sort things into a list, and then just grab bunches of them
and arbitrarily move them around.  You should instead do the grouping
first, so that the sort function has full information about the final
grouping.

As to how to treat the root, I guess the root of one of the gathered
threads should be simply chosen to be the root.  This could be done
using the existing settings for how gathered threads are handled,
or could be chosen using the sorting function for gathered threads.
Or a dummy root could be greated, and given a virtual article number,
date, score, etc, derived from the gathered threads.

[If I recall correctly, the order of articles within a thread is
controlled by the same sort function as the threads themselves.  If so,
it seems that this could extend to the gathered threads as well,
eliminating the need for a separate sort function to be set by the user.
In which case, the thread sorting function could be used to choose the
root of the thread.]

So there are some issues to sort out (no pun intended), but I think it
could make sorting much better and at least predictable.

Dan

PS: And just to emphasize, the current method seems to *always* get the
sorting wrong when gathering threads sorted by (not most-recent-date).