From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/87538 Path: news.gmane.org!.POSTED!not-for-mail From: Andrew Cohen Newsgroups: gmane.emacs.gnus.general Subject: Re: nnvirtual Date: Fri, 05 May 2017 20:51:46 +0800 Organization: Boston University Message-ID: <87mvar1n6l.fsf@hanan> References: <87mvauxgt9.fsf@hanan> <87y3udn7l9.fsf@ericabrahamsen.net> <87fuglfn1k.fsf@hanan> <87efw4gc2m.fsf@ericabrahamsen.net> <87r3031p4b.fsf@hanan> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1493988862 28666 195.159.176.226 (5 May 2017 12:54:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 5 May 2017 12:54:22 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: ding@gnus.org Original-X-From: ding-owner+m35753@lists.math.uh.edu Fri May 05 14:54:15 2017 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from mxfilter-048035.atla03.us.yomura.com ([107.189.48.35]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d6ckR-0007Fo-3s for ding-account@gmane.org; Fri, 05 May 2017 14:54:15 +0200 X-Yomura-MXScrub: 1.0 Original-Received: from lists1.math.uh.edu (unknown [129.7.128.208]) by mxfilter-048035.atla03.us.yomura.com (Halon) with ESMTPS id f31091a0-3191-11e7-b087-b499baabecb2; Fri, 05 May 2017 12:54:18 +0000 (UTC) Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.87) (envelope-from ) id 1d6ckB-0003QM-U0; Fri, 05 May 2017 07:54:00 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by lists1.math.uh.edu with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1d6ck8-0003Pb-0B for ding@lists.math.uh.edu; Fri, 05 May 2017 07:53:56 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtps (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.87) (envelope-from ) id 1d6ck6-0008Qr-Sy for ding@lists.math.uh.edu; Fri, 05 May 2017 07:53:55 -0500 Original-Received: from [195.159.176.226] (helo=blaine.gmane.org) by quimby.gnus.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1d6cjo-0006F6-3B for ding@gnus.org; Fri, 05 May 2017 14:53:39 +0200 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1d6cjh-0006SE-99 for ding@gnus.org; Fri, 05 May 2017 14:53:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 57 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:7IlFbf2cS1tGLfRrpACvygUCO08= List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:87538 Archived-At: >>>>> "Andrew" == Andrew Cohen writes: Eric> How does sorting work in select groups? Right now gnus-search Eric> does a pass in `gnus-search-run-query', sorting on rsv, but Eric> since nearly all engines return a score of 100, it's fairly Eric> meaningless. Eric> Summary buffer articles really are sorted according to the Eric> order returned by `gnus-search-run-query', which I find odd: Eric> shouldn't the normal `gnus-thread|article-sort-functions' Eric> routine kick in after group creation? Andrew> Yes, and that is how it behaves for me---nnselect buffers Andrew> are sorted exactly like any other gnus buffer. Not for you? Andrew> I wonder why... Andrew> (Aside: Various gnus functions require the article list to Andrew> be non-decreasing so in general the way nnselect works is to Andrew> sort the selection by group, and then ascending article Andrew> number within each group. This is how regular groups operate Andrew> as well. Any subsequent sorting in the summary buffer is Andrew> "virtual" in the sense that the article list itself isn't Andrew> changed.). And just to be a bit clearer on sorting. Gnus uses 2 different sorting functions: one for threaded display and one for unthreaded display. For unthreaded display the default is to sort by number, but you can sort any way you like (using either the canned gnus sort predicates or by rolling your own). As mentioned in my previous message gnus really wants article lists to be in non-decreasing order internally, so this means that a default unthreaded summary buffer will appear to be in the same order as the article list. For nnselect we first sort the selected articles by group and then ascending order within the group. This is usually the way they are retrieved in nnir (more or less deliberately) so it gives the appearance of using the order in which they are retrieved in nnir as the sort order but this isn't true; just try a different setting for gnus-article-sort-functions, for example this one: (setq gnus-article-sort-functions '(gnus-article-sort-by-number gnus-article-sort-by-subject)) (and of course you can check similar things if you are using a threaded display). So currently to use the RSV for sorting purposes requires constructing predicates that look at the RSV. This is trivial to do (and I'll probably include them as part of nnselect or in gnus-sum with the other sorting predicates at some point). But we can (and probably should) ignore any sorting issues coming out of gnus-search. Best, Andy