Re: Performance problem of imap move

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>
>>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>>
>>>> A local dovecot server, synced with gmail via isync.
>>>
>>> Ah.  For some reason, it seems that people running local IMAP servers
>>> triggers a lot of bugs in Gnus...
>>>
>>>> I've always meant to go and follow the code, but it's never been
>>>> annoying enough for me to actually do it. But if you're messing nnimap
>>>> at the moment anyway, maybe now's a good time.
>>>
>>> Please do.  :-)
>>
>> Doing this bit by bit, first of all here are the imap commands resulting
>> from moving article 39339 from INBOX to [Gmail].Trash, where it became
>> article 175. Upon leaving the INBOX group, [Gmail].Trash was marked as
>> containing 36 unread articles, when in fact it had none -- refreshing
>> Gnus reset the unread count to the proper value. Stepping through
>> `gnus-summary-move-article' and `nnimap-request-move-article' didn't
>> show anything immediately out of the ordinary, but I don't really
>> understand imap all that well.
>>
>> In a bit, I'll try it again and step through `nnimap-request-set-mark'.
>> That's what's being used to update marks on [Gmail].Trash, and seems
>> like the next most likely place to find bugs. Like I said, though, I
>> don't know imap all that well, so someone tell me if I should be looking
>> elsewhere.
>
> A little progress: `nnimap-request-set-mark' also looked normal, so I
> followed the `gnus-group-get-new-news-this-group' call at the end of
> `gnus-summary-move-article' instead.
>
> In the `let' in the middle of that (gnus-group.el:4081 in current Gnus),
> we call both `gnus-get-info' and `gnus-active' on the "group" variable.
> The return value of `gnus-get-info' indicates a "seen" range of (1 .
> 177), which is correct. The return value of `gnus-active' is (1 . 211),
> which isn't correct, and leads to the bogus unread count.
>
> Off to look at what's happening in `gnus-active'...

Ugh, it looks at gnus-active-hashtb. I think this is where I pass the
baton to someone else.