Re: gnus and imap

[David Engster <deng@randomsample.de>]

Vitaly Mayatskikh <v.mayatskih@gmail.com> writes:
>> There are surely some bugs - I sometimes get
>> wrong article counts when *entering* the group, which is kinda funny,
>> since it usually was vice versa. 
>
> That's interesting. Can you tell me how do you customize Gnus in your
> ~/.gnus (agent, cache, etc)?

The problem lies in gnus-read-active-file-2, which is called by
gnus-get-unread-articles. This uses nnimap-retrieve-groups to get a
partial active file of the checked groups, which is of the "regular"
(max . min) style and overwrites the previous "new" active sequence in
the hash table.

I'm not sure how to solve this. nnimap-retrieve-groups could return the
whole sequence, just like nnimap-request-group. Or we could change the
whole check-for-new-news sequence which is currently done by Gnus, so
that it does not use a partial active file.

Anyway, I have the feeling this gets messy. I'm not sure if this is the
right way to do this. The main problem I see is that this will break any
code which depends on gnus-active returning the cons (max . min). For
example, this currently breaks nnmairix, which isn't that much of a
problem since I can change this. But I wonder how much external code
exists which uses gnus-active.

We could solve this by extending the gnus-active macro, but this is
somewhat ugly, IMO. It may also be that there exists code (also in Gnus)
which directly accesses the hash table.

In my opinion, we should re-think your first effort, using group
info. You said:

> Well, it needs some special flag to detect old vs new backend. It looks
> like ugly solution for me :)

What about not extending the group info, but putting the unread sequence
in the existing marks section. Either the back end does this, then it
can be included, or we do it the old way. Just a suggestion, I don't
know if this works. As I said, I'm not that familiar with the back end
internals.

-David