Pterodactly gripe / oGnus wish

Pterodactly gripe / oGnus wish

[Michael Sperber [Mr. Preprocessor]]

I love my Pterodactyl.  Good riddance to tm!

But, at the risk of repeating something which has been said an
innumerable number of times already:

The numbering problem is the single most annoying aspect of Gnus.

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?

As the gaps between retained articles get larger, Gnus slows down
from a barely tolerable level to a quite intolerable one, even if
the total number of articles is quite slow.  Why?  I can't think of a
good reason algorithmically.

The fix described in the FAQ is a major kludge.  Why do people have
to be aware of the article numbers used internally by Gnus?  If the
FAQ answer has any sort of official status, why isn't there a
GNUS-GROUP-CLEANUP function bound to a convenient key that does the
job?

Fixing this should be a priority for oGnus at the latest.

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

Re: Pterodactly gripe / oGnus wish

[Karl Kleinpaste]

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?

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

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

Considering that the entire structure of Gnus is built on this
distinction between knowing the set of groups available (in *Group*)
and learning what is in a given group (as *Summary* is being built),
it will be extraordinarily difficult to "fix" this.  Consider that it
absolutely _cannot_ be fixed for nntp or nnspool groups, because Gnus
cannot affect that numbering at all -- long-held FAQ articles with
expiry times of months or more just plain hang around, unchanging.

> The fix described in the FAQ is a major kludge.  Why do people have
> to be aware of the article numbers used internally by Gnus?  If the
> FAQ answer has any sort of official status, why isn't there a
> GNUS-GROUP-CLEANUP function bound to a convenient key that does the
> job?

That, at least, is a good idea.  It would be a relatively simple
matter to bind some function so that, after one has entered a group
which is "too large" (pointlessly, I agree), one moves all the
articles to the same group, and thereby the excessive apparent size is
eliminated.

I suppose it's even possible to produce a hook to consider doing this
automatically, perhaps on group exit:
        if this is a mail group and
           group was "large" on entry and
           actual article count is in single digits
        then
           ask user whether to auto-cleanup group
        fi

--karl

Re: Pterodactly gripe / oGnus wish

[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

Re: Pterodactly gripe / oGnus wish

[Karl Kleinpaste]

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.

Re: Pterodactly gripe / oGnus wish

[Kai Großjohann]

Karl Kleinpaste <karl@justresearch.com> writes:

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

I think that Gnus could do better even with nntp groups.  For example,
there is a number for which Gnus knows that all articles less than
this number are read.  So the very old FAQ article with number 2 or
so, which has long been read, does not count in this algorithm.

I know that it will take some time to think about it, but I think
things can be improved.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Pterodactly gripe / oGnus wish

[Michael Sperber [Mr. Preprocessor]]

Hi Karl,

thanks for the extensive explanation.  I guess I'm slow with this:

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

Karl> sperber@informatik.uni-tuebingen.de writes:

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

But it seems the operation which consumes all that time is
constructing the Summary buffer, rather than counting the actual
number of articles.  Can't those two be decoupled, at least for the
local mail backends?

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