bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> AFAIK my use case is not completely unusual (typically connected via
> a NAT router to my university's IMAP server) and I see this problem more
> or less *every day*.
> So I really hope you can try to fix this soon.
> FWIW I never saw this problem with the old nnimap backend, so it's
> a (very serious if you ask me) regression w.r.t Emacs-23.

I've had a look at the nnimap in Emacs 23 to see whether I've missed
something, but it looks to me like that nnimap did exactly the same
thing as the Emacs 24 one does:  `nnimap-request-set-mark' is called on
group exit, and that's basically it.  (Marks are also altered when you
move messages and stuff, but for normal reading,
`nnimap-request-set-mark' on group exit is the main thing.)

So I don't understand how this has changed, really.  

> And I think it is related to the agent, because the connection death
> would be handled differently without the agent: the connection would be
> re-established and the command re-tried, whereas with the new
> "connection death silently puts the agent in offline mode", the command
> just gets dropped on the floor.

Oh, yeah, that's a definite possibility.  Did you use to get an "go
offline?" query on group exit?  In that case, that does sound like a
definite possible culprit, and shouldn't be difficult to reproduce and
fix... 

> That's probably what's going on (each folder is stored as a large single
> file).  Can the expunging be done asynchronously?

Not fully without opening a second connection to the IMAP server.  One
could just send off the "EXPUNGE" and not wait for the result, but it
means that the next IMAP command will have to wait instead, which will
feel like random hangs...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/