Re: nnimap doing redundant work?

[Simon Josefsson <jas@extundo.com>]

David Abrahams <dave@boost-consulting.com> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> David Abrahams <dave@boost-consulting.com> writes:
>>
>>>> How do you set up the nnimap server definition in Gnus (i.e.,
>>>> ~/.gnus or ~/.emacs snippet)?
>>>
>>> (setq gnus-select-method
>>>       '(nnimap "www.stlport.com"
>>>                (nnimap-address "www.stlport.com")
>>>                (nnimap-stream ssl)
>>>                (nnimap-authenticator login)
>>>                ))
>>
>> Perhaps this hasn't been tested much.  Could you kill all groups,
>> restart emacs with this definition instead:
>>
>> (setq gnus-select-method '(nnnil "")
>>       gnus-secondary-select-methods '((nnimap "www.stlport.com"
>>                 (nnimap-address "www.stlport.com")
>>                 (nnimap-stream ssl)
>>                 (nnimap-authenticator login)
>>                 )))
>
> nnimap: Updating info for nnimap+www.stlport.com:INBOX...done
> Retrieving newsgroup: nnimap+www.stlport.com:INBOX...
> nnimap: Updating info for nnimap+www.stlport.com:INBOX...done
> Fetching headers for nnimap+www.stlport.com:INBOX...done
> Generating summary...done
> No more unread articles
>
>
> Also, the group buffer was pretty strange after I did this; several
> groups appeared multiple times.  I had to kill them and re-check my
> subscriptions in order to clean things up.

Did you kill all groups and then resubscribed to them?  No mention of
the old groups in ~/.newsrc* when you press `s' in Gnus?

Do you have any customization when entering a group?  Or just any kind
of customization that might affect this?

>> If this solves it, it is probably easy to reproduce the problem.  If
>> you like to debug the lisp to see why this happens, that would be
>> appreciated.
>
> I'm very bad at elisp debugging (not very competent with edebug), but
> if there's a specifc thing you want me to look at I'll be happy to do
> it.

Let's try to get things into a working state first, then it is easier
to debug; just do a binary search between the working state and the
buggy state until the cause of the problem is found.  It still takes
some energy though, so perhaps you'll settle with simply having the
problem disappear.  But is useful too, the mailing list archive will
document this, in case someone wants to debug this in the future.