Re: nnvirtual

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Andrew Cohen <cohen@bu.edu> writes:

>>>>>> "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?

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.