Re: nnvirtual

[Andrew Cohen <cohen@bu.edu>]

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

    Eric> Andrew Cohen <cohen@bu.edu> writes:
    >>>>>>> "Eric" == Eric Abrahamsen <eric@ericabrahamsen.net> 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.

    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.

    Eric> Summary buffer articles really are sorted according to the
    Eric> order returned by `gnus-search-run-query', which I find odd:
    Eric> shouldn't the normal `gnus-thread|article-sort-functions'
    Eric> routine kick in after group creation? 

Yes, and that is how it behaves for me---nnselect buffers are sorted
exactly like any other gnus buffer. Not for you? I wonder why...

(Aside: Various gnus functions require the article list to be
non-decreasing so in general the way nnselect works is to sort the
selection by group, and then ascending article number within each
group. This is how regular groups operate as well. Any subsequent
sorting in the summary buffer is "virtual" in the sense that the article
list itself isn't changed.).

    Eric> Anyway, I'd just as soon not have gnus-search be responsible
    Eric> for sorting at all: it seems like passing on the rsv should be
    Eric> enough.  

Any sorting done by nnir (and now gnus-search) is purely
incidental. nnselect mangles the order anyway. So I think you should
safely ignore any issues with regard to the return order of the
articles.

    Eric> On the other hand, I'd sure like to let users specify a sort
    Eric> meta-key, like "sort:score,-date", but then that information
    Eric> would have to get passed down the line somehow. Perhaps
    Eric> something for later.

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.

    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> 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.