Re: gnus and imap

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

David Engster <deng@randomsample.de> writes:

>> 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 can't get this scenario (probably, due to different settings). Will dig
around more.

> 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.

As I understand, this change affects only "middle level" back ends like
yours nnmairix, which lays in between of Gnus and real transport back
ends. Of course, it is hard to say what exactly can be broken.

> 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.

We have sources and can fix this code ;) The only problem is a large
amount of regressions.

> 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.

I'm only afraid of spaghetti code. For me it's better to have one clean
and consistent solution.

Thanks for your help!

-- 
wbr, Vitaly