From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/87537 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:09:56 +0800 Organization: Boston University Message-ID: <87r3031p4b.fsf@hanan> References: <87mvauxgt9.fsf@hanan> <87y3udn7l9.fsf@ericabrahamsen.net> <87fuglfn1k.fsf@hanan> <87efw4gc2m.fsf@ericabrahamsen.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1493986346 6988 195.159.176.226 (5 May 2017 12:12:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 5 May 2017 12:12:26 +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+m35752@lists.math.uh.edu Fri May 05 14:12:19 2017 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from mxfilter-048034.atla03.us.yomura.com ([107.189.48.34]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d6c5q-0001cu-Ik for ding-account@gmane.org; Fri, 05 May 2017 14:12:18 +0200 X-Yomura-MXScrub: 1.0 Original-Received: from lists1.math.uh.edu (unknown [129.7.128.208]) by mxfilter-048034.atla03.us.yomura.com (Halon) with ESMTPS id 17129ffa-318c-11e7-8ed1-b499baa2b07a; Fri, 05 May 2017 12:12:22 +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 1d6c5A-00034l-9J; Fri, 05 May 2017 07:11:36 -0500 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by lists1.math.uh.edu with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1d6c56-000344-7Z for ding@lists.math.uh.edu; Fri, 05 May 2017 07:11:32 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtps (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.87) (envelope-from ) id 1d6c52-0003MW-0J for ding@lists.math.uh.edu; Fri, 05 May 2017 07:11:32 -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 1d6c50-0005pu-JW for ding@gnus.org; Fri, 05 May 2017 14:11:26 +0200 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1d6c4s-0000XG-85 for ding@gnus.org; Fri, 05 May 2017 14:11:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 103 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:vkxZIBL2kyBN5Y2UWnHFunWmTLw= List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:87537 Archived-At: >>>>> "Eric" == Eric Abrahamsen writes: Eric> Andrew Cohen writes: >>>>>>> "Eric" == Eric Abrahamsen writes: >> [...] Eric> I'd say we have to assume that, if the functionality is there, Eric> someone is using it, and combining groups is definitely Eric> something people do -- see Dovecot's virtual groups, for Eric> instance. Yes, I am not proposing eliminating it, I'm proposing making it more useful (but I don't know what that means yet:() Eric> As for the large newsgroup prompting, I think it would be Eric> desirable simply because it makes select groups behave like Eric> other Gnus groups, and means the limit isn't hardcoded. It Eric> short, it reduces users' mental friction when using select Eric> groups. Yes, I agree, and my intention is to add it (since its trivial) but first I want to know if I can make the whole thing more useful. Eric> Random other things: 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. I agree. I have gone back and forth about whether to eliminate it entirely. Eliminating it would allow some compression in various internal variables but this probably doesn't make much of a difference. But nnselect is currently ignoring the RSV---it is still available so that sorting functions can use it, however. nnselect is agnostic about the whole thing. 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? Yes, and that is how it behaves for me---nnselect buffers are sorted exactly like any other gnus buffer. Not for you? I wonder why... (Aside: Various gnus functions require the article list to be non-decreasing so in general the way nnselect works is to sort the selection by group, and then ascending article number within each group. This is how regular groups operate as well. Any subsequent sorting in the summary buffer is "virtual" in the sense that the article list itself isn't changed.). Eric> Anyway, I'd just as soon not have gnus-search be responsible Eric> for sorting at all: it seems like passing on the rsv should be Eric> enough. Any sorting done by nnir (and now gnus-search) is purely incidental. nnselect mangles the order anyway. So I think you should safely ignore any issues with regard to the return order of the articles. Eric> On the other hand, I'd sure like to let users specify a sort Eric> meta-key, like "sort:score,-date", but then that information Eric> would have to get passed down the line somehow. Perhaps Eric> something for later. All nnselect groups should be sorted exactly as any other gnus group, and should be as flexible as the usual sorting system. If that isn't working right its a bug. Eric> I've provided a count:t meta key in the search language, but Eric> it isn't used right now. The idea is that, if the user Eric> includes this key, the search returns a total number of hits Eric> per engine, rather than actually displaying the results (hits Eric> per group would be nice, but that information could be Eric> difficult extract from some engines). It will be fairly easy Eric> to hot-wire `gnus-group-make-search-group' to return this Eric> value, and permanent groups could simply strip it out. Hmm, the old nnir reported this (it went by too fast to be useful, but it was always available after the fact in the message buffer). Eric> If you like, it could also be a cheap way of updating message Eric> counts in permanent search groups. I note now that, at Eric> start-up for instance, the permanent groups do not show counts Eric> until they're entered. This is a temporary artifact of my not yet activating the groups at startup. The counts are all present and ready to be reported (as soon as the group is created), I just haven't gotten around to keeping the proper list of nnselect groups to allow activation and re-scanning as a matter of course. Eric> Sending a count request ought to be significantly cheaper than Eric> actually retrieving results, and might be useful. The counts are currently updated without retrieving any headers, and is therefore quite fast. For example I have a variety of groups with thousands of messages that are part of the nnselection and the time it takes to update the group is a fraction of a second.