From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/87544 Path: news.gmane.org!.POSTED!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.gnus.general Subject: Re: nnvirtual Date: Sun, 07 May 2017 10:39:39 +0800 Message-ID: <8737chjspg.fsf@ericabrahamsen.net> References: <87mvauxgt9.fsf@hanan> <87y3udn7l9.fsf@ericabrahamsen.net> <87fuglfn1k.fsf@hanan> <87efw4gc2m.fsf@ericabrahamsen.net> <87r3031p4b.fsf@hanan> <8737cjgvbx.fsf@ericabrahamsen.net> <87fugikf8m.fsf@hanan> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1494124876 20769 195.159.176.226 (7 May 2017 02:41:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 7 May 2017 02:41:16 +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+m35759@lists.math.uh.edu Sun May 07 04:41:11 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 1d7C8E-0005Ic-Qm for ding-account@gmane.org; Sun, 07 May 2017 04:41:10 +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 a3107166-32ce-11e7-8ed1-b499baa2b07a; Sun, 07 May 2017 02:41:14 +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 1d7C7U-0003fU-Ii; Sat, 06 May 2017 21:40:24 -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 1d7C7R-0003eo-1X for ding@lists.math.uh.edu; Sat, 06 May 2017 21:40:21 -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 1d7C7P-0003Do-Na for ding@lists.math.uh.edu; Sat, 06 May 2017 21:40:20 -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 1d7C7O-0004iK-9b for ding@gnus.org; Sun, 07 May 2017 04:40:18 +0200 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1d7C7F-0004JW-Sx for ding@gnus.org; Sun, 07 May 2017 04:40:09 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 70 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:HbVfGcYDW30VaKY0ZXs7DMkqGPQ= List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:87544 Archived-At: Andrew Cohen writes: >>>>>> "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? Whoops, that function did not survive the nnir->gnus-search transformation. I'll put it back in. I think that means I can just drop search presets. > 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. I see it's already in. BTW, that patch seems to have introduced a circular dependency between gnus-sum->nnselect->gnus-art->gnus-sum. I can't get it to compile. On a related note, I'm having a hard time finding a place to put the `gnus-group-make-search-group' functions: the call to nnselect-categorize also tends to create circular dependencies. Something to think about as this whole thing gets closer to completion. > 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. That's fine, I'm happy to drop the sorting stuff. > 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? No, it was just the thought that the engines might have an easier time returning a simple count than the results themselves (other engines return more than just UIDs). But I think I was just getting caught up in trying to expose and make use of everything the engines offer -- not really necessary.