Re: gnus and imap

[Vitaly Mayatskikh <v.mayatskih@gmail.com>]

David Engster <deng@randomsample.de> writes:

>> I can't get this scenario (probably, due to different settings). Will dig
>> around more.
>
> Try playing with gnus-read-active-file and call gnus-group-get-new-news
> with a level argument. nnimap is my primary select method, maybe this
> also comes into play.

May be so, because your test code doesn't show me the bug in my
configuration (nnnil is primary, two nnimaps are secondary).

>> I'm only afraid of spaghetti code. For me it's better to have one clean
>> and consistent solution.
>
> Absolutely. The problem is that active information is used throughout
> Gnus, and the code is in parts already pretty convoluted, especially the
> ones dealing with updating groups and checking for unread messages. I
> guess that putting unread information in gnus-info would affect fewer
> parts of the code.

Yes, but we still have to fix all this convoluted code (for
gnus-unread-info or whatever). Unread articles calculations (count of
articles, list of articles) are totally wrong for the case of IMAP.

> Another suggestion: maybe all this work should be strictly kept in the
> back end itself?  We could implement a new back end function, like
> 'nnimap-unread-articles GROUP SERVER', which just returns the number of
> unread articles. We can check for the existence of specific back end
> functions with gnus-check-backend-function, so no need for additional
> flags.

It might be a good idea to extend api of back ends. By the way, have Gnus
developers any plans of doing large changes in Gnus, like refactoring,
global cleanup, etc?

-- 
wbr, Vitaly