[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mis-counting articles
- To: nnimap@extundo.com
- Subject: Re: mis-counting articles
- From: Simon Josefsson <jas@pdc.kth.se>
- Date: 07 Jul 1999 11:55:49 +0200
- In-Reply-To: Rajesh Godbole's message of "06 Jul 1999 15:12:44 -0700"
- References: <8t6oghpfmw3.fsf@Corp.Sun.COM>
- User-Agent: Gnus/5.070091 (Pterodactyl Gnus v0.91) Emacs/20.3.11
Rajesh Godbole <argv@Sun.COM> writes:
> [ Tech-News -- 291 ]
> 47: nnimap+aries:Mail/ding
> 158: nnimap+aries:Mail/suncluster
> 86: nnimap+aries:Mail/all-ambassador
>
> when I enter Mail/ding, it prompt me for the # of articles, so I enter
> 47. After entering the group it shows all 47 articles are read.
> The separator show {0(+47) more} articles.
>
> If I fetch significantly more # of articles, I'm still unable to see
> those (+47) articles that pgnus/nnimap thinks are unread.
It's a known "feature" -- the unread count in Gnus is documented to be
only a estimate, and it will be wrong if you use another imap client
to read (or unread) articles or if there are holes in the UID range.
This quite silly NNTP legacy could be fixed by introducing a new
(optional) backend function to ask for number of unread articles in a
group, and a new `gnus-group-line-format' character that show the
result of that function, or the old estimate if the function isn't
available in the backend. Opinions? Lars?
Meanwhile, you could put this (after (require 'nnimap)) in your .gnus
(deffoo nnimap-request-update-info (group info &optional server)
(nnimap-request-update-info-internal group info server))
but I think you'll find things too slow, at least I did.