Re: Performance problem of imap move

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Tassilo Horn <tsdh@gnu.org> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>>> This will have to be refactored a bit, and a new nnimap function will
>>> have to be written, I think...
>>
>> I've now done this, so moving IMAP messages to large groups should be
>> faster again.
>
> I don't know if that's a side-effect of this change but with today's
> Gnus version I sometimes get group lines like
>
>     38289: nnimap+Server:some.group
>
> where actually there are no unread articles in the group.  `M-g' on the
> group or another `g' fixes the unread count again.
>
> I also don't have a reproducible recipe but it seems to happen
> sporadically with random nnimap groups.  Not sure what I did before.
> Possibly, it happens when some.group is either my sent-mail or SPAM
> group, and previously I've sent a new mail or exited some other group
> where I've marked some messages as SPAM which are moved to my SPAM group
> as a result...
>
> Bye,
> Tassilo

I see something like this (and have for a very long time, this isn't
new) when moving messages between nnimap groups. When I open an imap
group containing new messages, and decide that one of the
(newly-received but now marked "read") messages belongs in a different
group on the same server, I move it to that group, return to the *Group*
buffer, and see that the group I moved the message to now has an
(apparently random) unread count. Hitting "g" or actually entering the
group makes the unread count go away -- the messages aren't actually
marked as unread.

Might be unrelated, though: as I said, it's done this (fairly
reproducibly) for a long time.