From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/79025 Path: news.gmane.org!not-for-mail From: Dan Christensen Newsgroups: gmane.emacs.gnus.general Subject: Re: Problem with thread sorting Date: Sat, 04 Jun 2011 20:34:10 -0400 Message-ID: <87k4d1dsl9.fsf@uwo.ca> References: <87hb94f4yk.fsf@micropit.couberia.bzh> <878vtn8hnk.fsf@micropit.couberia.bzh> <878vtkcojo.fsf@uwo.ca> <87mxhymtr1.fsf@micropit.couberia.bzh> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1307234150 18311 80.91.229.12 (5 Jun 2011 00:35:50 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 5 Jun 2011 00:35:50 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M27325@lists.math.uh.edu Sun Jun 05 02:35:47 2011 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QT1Ji-00085L-MM for ding-account@gmane.org; Sun, 05 Jun 2011 02:35:47 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1QT1IZ-0008VE-4c; Sat, 04 Jun 2011 19:34:35 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1QT1IX-0008V4-HV for ding@lists.math.uh.edu; Sat, 04 Jun 2011 19:34:33 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1QT1IQ-00048A-8O for ding@lists.math.uh.edu; Sat, 04 Jun 2011 19:34:30 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1QT1IN-00023D-AQ for ding@gnus.org; Sun, 05 Jun 2011 02:34:23 +0200 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QT1IM-0007lx-O7 for ding@gnus.org; Sun, 05 Jun 2011 02:34:22 +0200 Original-Received: from bas2-london14-1167882109.dsl.bell.ca ([69.156.119.125]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 05 Jun 2011 02:34:22 +0200 Original-Received: from jdc by bas2-london14-1167882109.dsl.bell.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 05 Jun 2011 02:34:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: ding@gnus.org Original-Lines: 73 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: bas2-london14-1167882109.dsl.bell.ca User-Agent: Gnus/5.110012 (No Gnus v0.12) Emacs/23.1 (gnu/linux) Mail-Copies-To: never Cancel-Lock: sha1:Wh1w3CO0HDleRteKIP41tZN80G4= X-Spam-Score: -4.9 (----) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:79025 Archived-At: Lars Magne Ingebrigtsen 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).