Re: How many articles to read...?

[Karl Kleinpaste <karl@justresearch.com>]

Dmitry Yaitskov <dimas@home.com> writes:
> Is it a bug or a feature? 

Depends on how you look at it.  For precision, it's a bug.  For
simplicity, it's a feature.

> I mean, I don't really care about the articles' numbers and have no
> way to control them, why doesn't gnus show e.g. the number of
> entires (lines?) in the .overview file instead? 

Because that can be very, very expensive.

Consider Gnus as a newsreader.  (Mail handling is just Gnus looking at
something news-like while stoned on really bad crack.)  You enter a
group, and Gnus picks up the active file's concept of lowest- and
highest-numbered article.  What's the simplest conception that can be
provided as to how many articles are probably there?

Simply subtract, of course.  The delta is "close," in the usual (news)
case, where articles arrive sequentially, and (usually) are deleted
off the low end in large batches during expiry runs, leaving no
article numbering holes.

Now come to mail, where we have massive amounts of peculiar control
that isn't typical of a news system.  We move articles around, copy
them, delete them, all of these things knocking around the limits in
the mail active file.  What's Gnus to do?  Start reading the entirety
of every .overview it runs into?  That's an awful lot of wasted I/O,
and a lot of wasted time spent counting lines, considering how few
entries from the typical .overview are really relevant during any
given arrival in either a news or mail group.  I have nnml groups with
4000 articles in them -- I do not want multi-megabyte .overviews being
read, every time I enter the group.

So you learn to live with mail groups' counts being wrong, or...

> Can this behavior somehow be changed without seeting the limit to
> INT_MAX?

- Enter the group now mistakenly perceived as having too many articles.
- Process-mark the whole set.
- `B m' to move them all to the same group.

The resulting article range will be contiguous and relatively narrow.