Some numbering problem (nnml?)

Some numbering problem (nnml?)

[Fabrice Gamberini]

Hello,

I'm using Gnus v5.8.7 on NT-Emacs (20.7.1), mostly for email since I have no
news server ATM. nnml is my backend of choice. 

There's this mailing-list I'm subscribed to, which generates a volume of
roughly a hundred messages a day; this group has auto-expiry.
 
I have sometimes deleted expired mesages manually, and sometimess deleted
(B-del) messages myself. The problem is that the number of total messages in
this group does not seem to decrease at all -as presented when I want to open
it and there's no new message. Gnus will says something like "how many messages
do you want to read (default 7293) ?". This number always goes up, and now it
doesn't reflect the REAL number of messages that haven't been deleted yet
(this is easy to find, only count the individual files in ~/Mail/list/foo) .

Is there a command to make Gnus recount the effective number of messages in a
group ??

thanks 



-- 
Fabrice Gambérini
  -- = Wavecom S.A. = -- 
Email: fabrice.gamberini@wavecom.fr

Re: Some numbering problem (nnml?)

[Kai Großjohann]

On 01 Dec 2000, Fabrice Gamberini wrote:

> Is there a command to make Gnus recount the effective number of
> messages in a group ??

The number that Gnus initially shows is based on the difference
between the highest and the lowest article number.  If there are many
`holes' in the article number sequence, the estimate can be way off.

You could `C-u RET' to enter the group, showing all articles.  Then
you mark them all with `M P a', then `B m' them into the same group.
This will close the holes.

kai
-- 
The arms should be held in a natural and unaffected way and never
be conspicuous. -- Revised Technique of Latin American Dancing

Re: Some numbering problem (nnml?)

[Harry Putnam]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> On 01 Dec 2000, Fabrice Gamberini wrote:
> 
> > Is there a command to make Gnus recount the effective number of
> > messages in a group ??
> 
> The number that Gnus initially shows is based on the difference
> between the highest and the lowest article number.  If there are many
> `holes' in the article number sequence, the estimate can be way off.
> 
> You could `C-u RET' to enter the group, showing all articles.  Then
> you mark them all with `M P a', then `B m' them into the same group.
> This will close the holes.

In my short time using gnus (since about Quassia-12 or so) I've seen
this topic come up probably over 1000 times.   I've wondered a time or
two why we do not have a better way to give accurate numbers for
articles in a group. 

Kai's remedy works for mail groups and has been posted many times too.
Not detracting from the remedy, which was clearly given for mail
groups, But it doesn't work for nntp/agentized groups.

The current High-Low method is known to be ridiculously inaccurate in
Mail and Agentized groups, because of expiry, messages movement (B m)
etc. (esp. if `gnus-agent-expire' is run occassionally).

It seems that if gnus is capable of assembling a summary buffer
containing all messages, it would be able to count them too. 

The high-low mechanism seems ok for the days when gnus was an on-line
only reader.  But has never been good for mail, and now many of us
have agentized articles in those nntp groups too.

How hard can it really be for gnus to count files on disk for mail
groups?  And maybe compile some combination of data from nntp server
and actual count for nntp groups.

-- 
"Boxes not Boxen" 
Join the growing movement to EtUUoPP (End the Useless Use of
Pretentious Plurals). Strike a blow for plain talk: 
Adopt the ultimate witty signature .. "Boxes not Boxen"

Re: Some numbering problem (nnml?)

[Paul Jarc]

Harry Putnam <reader@newsguy.com> writes:
> How hard can it really be for gnus to count files on disk for mail
> groups?

That's done by individual backends, not Gnus proper.  But anyway,
backends already report the number of articles in the output of
-request-group.  Gnus ignores this in favor of last-first+1 (according
to the 5.8.7 texinfo).  Anyone know why?  Obviously, backends are
capable of making at least as good an estimate as that, and probably
much better.  Some backends might not actually do this, but this seems
like a bad way to handle them.


paul

Re: Some numbering problem (nnml?)

[ShengHuo ZHU]

prj@po.cwru.edu (Paul Jarc) writes:

> Harry Putnam <reader@newsguy.com> writes:
> > How hard can it really be for gnus to count files on disk for mail
> > groups?
> 
> That's done by individual backends, not Gnus proper.  But anyway,
> backends already report the number of articles in the output of
> -request-group.  Gnus ignores this in favor of last-first+1 (according
> to the 5.8.7 texinfo).  Anyone know why?  Obviously, backends are
> capable of making at least as good an estimate as that, and probably
> much better.  Some backends might not actually do this, but this seems
> like a bad way to handle them.

One reason is that the number doesn't help much to calculate the
number of unread articles.  For example, -request-group returns 3 5 9
(the number of articles, first, last), and you've read 5-8. What is
the number of unread articles?  Gnus doesn't know whether number 9 is
missing.

ShengHuo

Re: Some numbering problem (nnml?)

[Paul Jarc]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:
> prj@po.cwru.edu (Paul Jarc) writes:
> > But anyway, backends already report the number of articles in the
> > output of -request-group.  Gnus ignores this in favor of
> > last-first+1 (according to the 5.8.7 texinfo).  Anyone know why?
> 
> One reason is that the number doesn't help much to calculate the
> number of unread articles.

Ok, but when using C-u RET, you don't need the number of unread
articles, just the total.  Yet in that case, Gnus still prompts you
with last-first+1.

> For example, -request-group returns 3 5 9 (the number of articles,
> first, last), and you've read 5-8. What is the number of unread
> articles?  Gnus doesn't know whether number 9 is missing.

What if the number of articles reported by the backend is smaller than
last-first+1-(number of read articles)?  In that case, we can improve
the estimate by using the backend's number, even by assuming that all
of those are unread.  (This may not be a common case, but it isn't
expensive to handle, either.)


paul