Re: nnvirtual

[Andrew Cohen <cohen@bu.edu>]

>>>>> "Eric" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:

    >>>>>>> "Eric" == Eric Abrahamsen <eric@ericabrahamsen.net> 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.