From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/87540 Path: news.gmane.org!.POSTED!not-for-mail From: Andrew Cohen Newsgroups: gmane.emacs.gnus.general Subject: Re: nnvirtual Date: Sat, 06 May 2017 08:20:41 +0800 Organization: Boston University Message-ID: <87fugikf8m.fsf@hanan> References: <87mvauxgt9.fsf@hanan> <87y3udn7l9.fsf@ericabrahamsen.net> <87fuglfn1k.fsf@hanan> <87efw4gc2m.fsf@ericabrahamsen.net> <87r3031p4b.fsf@hanan> <8737cjgvbx.fsf@ericabrahamsen.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1494030107 2641 195.159.176.226 (6 May 2017 00:21:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 6 May 2017 00:21:47 +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+m35755@lists.math.uh.edu Sat May 06 02:21:43 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 1d6nTi-0000YW-AP for ding-account@gmane.org; Sat, 06 May 2017 02:21:42 +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 fc339283-31f1-11e7-b087-b499baabecb2; Sat, 06 May 2017 00:21:44 +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 1d6nT0-0000CH-Ul; Fri, 05 May 2017 19:20:59 -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 1d6nSx-0000Bd-3j for ding@lists.math.uh.edu; Fri, 05 May 2017 19:20:55 -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 1d6nSv-00052i-SZ for ding@lists.math.uh.edu; Fri, 05 May 2017 19:20: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 1d6nSt-00059u-Aq for ding@gnus.org; Sat, 06 May 2017 02:20:51 +0200 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1d6nSl-000838-SM for ding@gnus.org; Sat, 06 May 2017 02:20:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 97 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:bnwetOzcXRHSr0cyY5lqMEmK96Y= List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:87540 Archived-At: >>>>> "Eric" == Eric Abrahamsen writes: >>>>>>> "Eric" == Eric Abrahamsen writes: >> [...] Eric> But if, for example, it were possible to start a search from Eric> within a summary buffer, saying "run this search within this Eric> group", then presets might not be necessary: users could Eric> create permanent select groups incorporating several other Eric> groups, then run ad-hoc searches within them. Umm, this has always been possible with nnir. Does it not work for you? [...] And wrt RSV scoring. Eric> I'd still like to keep it, and the infrastructure to support Eric> it. It might become more useful later. Namazu hints that it Eric> supports scoring (I really need to get a working Eric> installation), imap returns relevancy with FUZZY, and future Eric> engines for solr or xapian-based stuff would provide scoring. I used namazu with its scoring for many years. Aside from trying out the scoring and seeing that it all worked I never used it in practice. I find these scores (from search engines in general) very much not useful. But I decided early on after my back and forth that there is little cost in keeping it, and making the proper predicate is easy and on my todo list. [...] Eric> Responding to both messages here: if there were a new Eric> predicate for sorting on score, I think we'd be fine. Part of Eric> me still would like to let users specify sorting strategies on Eric> the fly, as part of the search query. Sorting could also be Eric> passed to the backends, and combined with limit:n could result Eric> in faster queries. At this point that's probably more work Eric> than it's worth, though. I definitely think that gnus-search should stay away from any kind of sorting. Modulo bugs the gnus strategy of sorting as an overlay on summary buffers works great. 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> Right, but the idea is that sometimes the count itself is all Eric> 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. Eric> Well, it's probably premature optimization. But it would be Eric> pretty simple to implement... I don't think its a real optimization. All the time now is taken in setting up the connection; the search itself would take the same time, the only difference being you might not be returning the list of UIDs. But parsing the UIDs takes essentially no time. Unless you had something else in mind? Also nnselect isn't about searching---there are many other ways that selection lists can be produced.