Re: nnvirtual

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Andrew Cohen <cohen@bu.edu> writes:

>>>>>> "Eric" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>     Eric> Andrew Cohen <cohen@bu.edu> writes:
>     >> Gnus has had the nnvirtual backend, allowing several newsgroups
>     >> to be read as a single, combined newsgroup, for ages. But is
>     >> anyone using it?  And if so, how and why?
>
> [...]
>
>
>     Eric> (Me again.)
>
>     Eric> Is there a way to make use of Gnus' existing "big group"
>     Eric> behavior?  Meaning, add the active numbers, and if it's more
>     Eric> than `gnus-large-newsgroup', prompt the user for the number of
>     Eric> articles to retrieve? Or is that happening at a different
>     Eric> level of infrastructure?
>
> Different level of infrastructure. But its not hard to solve this
> problem (in fact the limit variable that I stuck in by hand does almost
> exactly what the large newsgroup variable does, minus the prompting
> which would be trivial to add). But I am trying to understand what
> functionality would be served by any of this to decide how best to
> handle it.
>
> My real guess is that no one is using it and there it serves no
> purpose. In which case the simplest solution is probably the best one:)

I'd say we have to assume that, if the functionality is there, someone
is using it, and combining groups is definitely something people do --
see Dovecot's virtual groups, for instance.

As for the large newsgroup prompting, I think it would be desirable
simply because it makes select groups behave like other Gnus groups, and
means the limit isn't hardcoded. It short, it reduces users' mental
friction when using select groups.

Random other things:

How does sorting work in select groups? Right now gnus-search does a
pass in `gnus-search-run-query', sorting on rsv, but since nearly all
engines return a score of 100, it's fairly meaningless. Summary buffer
articles really are sorted according to the order returned by
`gnus-search-run-query', which I find odd: shouldn't the normal
`gnus-thread|article-sort-functions' routine kick in after group
creation? Anyway, I'd just as soon not have gnus-search be responsible
for sorting at all: it seems like passing on the rsv should be enough.
On the other hand, I'd sure like to let users specify a sort meta-key,
like "sort:score,-date", but then that information would have to get
passed down the line somehow. Perhaps something for later.

I've provided a count:t meta key in the search language, but it isn't
used right now. The idea is that, if the user includes this key, the
search returns a total number of hits per engine, rather than actually
displaying the results (hits per group would be nice, but that
information could be difficult extract from some engines). It will be
fairly easy to hot-wire `gnus-group-make-search-group' to return this
value, and permanent groups could simply strip it out.

If you like, it could also be a cheap way of updating message counts in
permanent search groups. I note now that, at start-up for instance, the
permanent groups do not show counts until they're entered. Sending a
count request ought to be significantly cheaper than actually retrieving
results, and might be useful.

Anyway, just a possibility.

E