nnimap and Unread message count

nnimap and Unread message count

[Nevin Kapur]

Gnus/nnimap is how I usually access my email. Occasionally, I also use
some other mail clients on some other machines.  Consequently, I have
nnimap-split-predicate set to "UNDELETED".

Often when I come back to Gnus after having access my mail with some
other mail client, after splitting, the unread count for groups which
get articles is wrong. As soon as I try to access any group with these
bogus unread count, Gnus (correctly) tells me that there are no unread
articles in that group.

I would like to know if there is any way around this, i.e., can nnimap
not "know" that some of the articles that were split are already read?

-- 
Nevin Kapur
nevin@jhu.edu 

Re: nnimap and Unread message count

[Kai Großjohann]

Nevin Kapur <nevin@jhu.edu> writes:

> Often when I come back to Gnus after having access my mail with some
> other mail client, after splitting, the unread count for groups which
> get articles is wrong. As soon as I try to access any group with these
> bogus unread count, Gnus (correctly) tells me that there are no unread
> articles in that group.

Argh, these unread counts in the Group buffer.  I'm sure many people
have cursed them wrong estimates.

Does it help to hit M-g on the group in the Group buffer?

Is somebody willing to change the Gnus implementation to display the
correct unread count if provided by the backend?  I think this just
means that the %N and %y specs need to be changed to make use of the
additional data from the backend.  Hm.  But I don't know how this is
done.  Hm.

kai
-- 
Abort this operation?   [OK]  [Cancel]

Re: nnimap and Unread message count

[Nevin Kapur]

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

> Nevin Kapur <nevin@jhu.edu> writes:
>
>> Often when I come back to Gnus after having access my mail with some
>> other mail client, after splitting, the unread count for groups which
>> get articles is wrong. As soon as I try to access any group with these
>> bogus unread count, Gnus (correctly) tells me that there are no unread
>> articles in that group.
>
> Argh, these unread counts in the Group buffer.  I'm sure many people
> have cursed them wrong estimates.
>
> Does it help to hit M-g on the group in the Group buffer?

Not very much. It updates the unread article count to some other bogus
number. In some cases, this number is correct, in others, it isn't.

-- 
Nevin Kapur
nevin@jhu.edu 

Re: nnimap and Unread message count

[Paul Jarc]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote:
> Is somebody willing to change the Gnus implementation to display the
> correct unread count if provided by the backend?  I think this just
> means that the %N and %y specs need to be changed to make use of the
> additional data from the backend.  Hm.  But I don't know how this is
> done.  Hm.

Idea: nnchoke-retrieve-groups can choose to report an article count or
just give the high/low numbers.  Gnus could use that count if given,
and use the high-low difference otherwise.  Backends would have to be
checked to make sure they don't report the count if it's not accurate.


paul