Re: gnus and imap

[David Engster <deng@randomsample.de>]

Vitaly Mayatskikh <v.mayatskih@gmail.com> writes:
>> 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.

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.

I tested this with

(save-excursion
  (set-buffer gnus-group-buffer)
  (gnus-group-jump-to-group "sent")
  (gnus-group-get-new-news-this-group)
  (princ (gnus-active "sent") t);; will return full range
  (gnus-group-get-new-news 3)
  (princ (gnus-active "sent") t) ;; returns one range, e.g. (1 . 2500)
)

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

That's right (both statements).

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

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.

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.

-David