Re: Pterodactly gripe / oGnus wish

[sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])]

>>>>> "Karl" == Karl Kleinpaste <karl@justresearch.com> writes:

Karl> sperber@informatik.uni-tuebingen.de writes:
>> I look at the *Groups* buffer.  It displays the correct number of
>> (ticked) articles in a group.  I enter the group and it prompts me
>> with a totally bogus number of articles to fetch.  Why can't Gnus
>> count at least as well as I can?

Karl> Because at the point of construction of the *Group* buffer, Gnus does
Karl> not know what is inside individual groups.  Gnus knows what the active
Karl> file says about the group, which is nothing more than a high and low
Karl> value for article numbers.

But the number in *Group* is *right*.  The number it prompts me with
is wrong.  Why?

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.

Karl> Gnus does not discover the gap until it enters the group.  When you
Karl> tell it to do so, all it sees is that "low" subtracted from "high" is
Karl> a number of potential articles which is larger than the
Karl> gnus-large-newsgroup variable.  So it bugs you with a question.

Karl> Considering that the entire structure of Gnus is built on this
Karl> distinction between knowing the set of groups available (in *Group*)
Karl> and learning what is in a given group (as *Summary* is being built),
Karl> it will be extraordinarily difficult to "fix" this.

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.

Karl> Consider that it absolutely _cannot_ be fixed for nntp or
Karl> nnspool groups,

Sure, I can see that.  I don't need it fixed there, I need it fixed
for nnml groups.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla