From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/87539 Path: news.gmane.org!.POSTED!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.gnus.general Subject: Re: nnvirtual Date: Fri, 05 May 2017 23:46:42 +0800 Message-ID: <8737cjgvbx.fsf@ericabrahamsen.net> 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 1493999295 3009 195.159.176.226 (5 May 2017 15:48:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 5 May 2017 15:48:15 +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+m35754@lists.math.uh.edu Fri May 05 17:48:11 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 1d6fSk-0000eD-PZ for ding-account@gmane.org; Fri, 05 May 2017 17:48:10 +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 3ed3aa0c-31aa-11e7-b087-b499baabecb2; Fri, 05 May 2017 15:48:13 +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 1d6fS5-0004l7-W2; Fri, 05 May 2017 10:47:30 -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 1d6fS2-0004kX-2j for ding@lists.math.uh.edu; Fri, 05 May 2017 10:47:26 -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 1d6fS0-0005J9-Er for ding@lists.math.uh.edu; Fri, 05 May 2017 10:47:25 -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 1d6fRy-00085E-7E for ding@gnus.org; Fri, 05 May 2017 17:47:23 +0200 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1d6fRp-0007yz-WC for ding@gnus.org; Fri, 05 May 2017 17:47:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 119 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:2iWya9cCTL5yDLzBzEqk0rSiNMQ= List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:87539 Archived-At: Andrew Cohen writes: >>>>>> "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. Yeah, I'm not sure either. The two general principles I'm after are: give users the ability to set up commonly-used patterns, and at the same time give them as much flexibility as possible. I mentioned earlier the idea of search "presets", the code for which is pretty much done (and very simple). Each preset is a list of groups to search, and a base search query. The user selects a preset, adds additional query terms, an ephemeral search group is created. I made this because it seemed like the right balance between configuration and flexibility. But if, for example, it were possible to start a search from within a summary buffer, saying "run this search within this group", then presets might not be necessary: users could create permanent select groups incorporating several other groups, then run ad-hoc searches within them. All of which is only to say that I don't really know, either. But Gnus users are a strange bunch, I'd say support as much as possible. > 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. I'd still like to keep it, and the infrastructure to support it. It might become more useful later. Namazu hints that it supports scoring (I really need to get a working installation), imap returns relevancy with FUZZY, and future engines for solr or xapian-based stuff would provide scoring. > 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. > 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. Responding to both messages here: if there were a new predicate for sorting on score, I think we'd be fine. Part of me still would like to let users specify sorting strategies on the fly, as part of the search query. Sorting could also be passed to the backends, and combined with limit:n could result in faster queries. At this point that's probably more work than it's worth, though. > 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). Right, but the idea is that sometimes the count itself is all you want to see. > 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. Well, it's probably premature optimization. But it would be pretty simple to implement...