Re: Pterodactly gripe / oGnus wish

[Karl Kleinpaste <karl@justresearch.com>]

sperber@informatik.uni-tuebingen.de writes:
> But the number in *Group* is *right*.  The number it prompts me with
> is wrong.  Why?

Because it has reason to want to offer you other articles besides just
those few that are ticked.  It has an (unreal) large set of articles
to offer you.  If you have, say, 3 articles ticked, and yet you have a
group with 350 articles available, it will still query.  If all that
remains in the group is the set of 3 ticked articles, then Gnus should
not be querying you.  *That* much, Gnus knows, but only because it's
additional state which Gnus has stored in .newsrc.eld.

> And why can't Gnus look up the relevant information when constructing
> the *Group* buffer?  At the latest, it should look it up when it
> prompts me for a number.  There's something fundamental I'm not
> getting here, or there's a fundamental design flaw in Gnus.

The whole point of the query is to ask if you really want Gnus to
commit to spending all that time, constructing all that information,
for some apparently-but-unreal very large set of articles.

Try an experiment: Simply set gnus-large-newsgroup to some
astronomical number.  100000 or so.  Then experiment with group entry,
see what happens.

The point here is this: Gnus believes there's some large set of
articles.  The time when Gnus learns whether this is a real estimate
occurs *after* Gnus has committed itself to retrieving potentially
hundreds or thousands of articles' worth of overview data.  That will
occupy a lot of time over a slow link, and will make Gnus spend a lot
of time computing a *Summary* buffer.

Once Gnus has begun retrieving the information about what articles
actually exist, you can't stop it.  It's a synchronous process.

What I'm getting at is that you can't say "look it up, then ask me,"
because it is the very process of looking it up that the query is
trying to stop.  "Looking it up" is the expensive activity in question.

> Well, OK.  But why does Gnus have to get unbearably slow when dealing
> with these gaps?  This is really the worst aspect of the problem.

That's a very good question, and one which I can't answer.  But
personally, I don't notice this slowdown in the first place.