From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/87536 Path: news.gmane.org!.POSTED!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.gnus.general Subject: Re: nnvirtual Date: Fri, 05 May 2017 12:30:25 +0800 Message-ID: <87efw4gc2m.fsf@ericabrahamsen.net> References: <87mvauxgt9.fsf@hanan> <87y3udn7l9.fsf@ericabrahamsen.net> <87fuglfn1k.fsf@hanan> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1493958732 10549 195.159.176.226 (5 May 2017 04:32:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 5 May 2017 04:32:12 +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+m35751@lists.math.uh.edu Fri May 05 06:32:08 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 1d6UuW-0002de-3q for ding-account@gmane.org; Fri, 05 May 2017 06:32:08 +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 cc8d27fc-314b-11e7-b087-b499baabecb2; Fri, 05 May 2017 04:32:09 +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 1d6UtZ-00082b-8D; Thu, 04 May 2017 23:31:09 -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 1d6UtW-000828-M6 for ding@lists.math.uh.edu; Thu, 04 May 2017 23:31:06 -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 1d6UtV-0000Pu-Ag for ding@lists.math.uh.edu; Thu, 04 May 2017 23:31:06 -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 1d6UtT-0000zD-UY for ding@gnus.org; Fri, 05 May 2017 06:31:03 +0200 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1d6UtM-0001NU-HQ for ding@gnus.org; Fri, 05 May 2017 06:30:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 70 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:GJ9SxzmGo/fU32O+c/7cqtzuAeA= List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:87536 Archived-At: Andrew Cohen writes: >>>>>> "Eric" == Eric Abrahamsen writes: > > Eric> Andrew Cohen writes: > >> Gnus has had the nnvirtual backend, allowing several newsgroups > >> to be read as a single, combined newsgroup, for ages. But is > >> anyone using it? And if so, how and why? > > [...] > > > Eric> (Me again.) > > Eric> Is there a way to make use of Gnus' existing "big group" > Eric> behavior? Meaning, add the active numbers, and if it's more > Eric> than `gnus-large-newsgroup', prompt the user for the number of > Eric> articles to retrieve? Or is that happening at a different > Eric> level of infrastructure? > > Different level of infrastructure. But its not hard to solve this > problem (in fact the limit variable that I stuck in by hand does almost > exactly what the large newsgroup variable does, minus the prompting > which would be trivial to add). But I am trying to understand what > functionality would be served by any of this to decide how best to > handle it. > > My real guess is that no one is using it and there it serves no > purpose. In which case the simplest solution is probably the best one:) I'd say we have to assume that, if the functionality is there, someone is using it, and combining groups is definitely something people do -- see Dovecot's virtual groups, for instance. As for the large newsgroup prompting, I think it would be desirable simply because it makes select groups behave like other Gnus groups, and means the limit isn't hardcoded. It short, it reduces users' mental friction when using select groups. Random other things: How does sorting work in select groups? Right now gnus-search does a pass in `gnus-search-run-query', sorting on rsv, but since nearly all engines return a score of 100, it's fairly meaningless. Summary buffer articles really are sorted according to the order returned by `gnus-search-run-query', which I find odd: shouldn't the normal `gnus-thread|article-sort-functions' routine kick in after group creation? Anyway, I'd just as soon not have gnus-search be responsible for sorting at all: it seems like passing on the rsv should be enough. On the other hand, I'd sure like to let users specify a sort meta-key, like "sort:score,-date", but then that information would have to get passed down the line somehow. Perhaps something for later. I've provided a count:t meta key in the search language, but it isn't used right now. The idea is that, if the user includes this key, the search returns a total number of hits per engine, rather than actually displaying the results (hits per group would be nice, but that information could be difficult extract from some engines). It will be fairly easy to hot-wire `gnus-group-make-search-group' to return this value, and permanent groups could simply strip it out. If you like, it could also be a cheap way of updating message counts in permanent search groups. I note now that, at start-up for instance, the permanent groups do not show counts until they're entered. Sending a count request ought to be significantly cheaper than actually retrieving results, and might be useful. Anyway, just a possibility. E