4266 is the 666 of the IMAP world (retrieval issues and odd behaviours)

[Matt Ford <matt@dancingfrog.co.uk>]

Hi,

Returned to Gnus after hearing that all IMAP code is spiffy fast
again...which it is :-) But I do have some issues...

I've checked out the latest (as of a couple of days ago) git development
branch and configured Gnus to run against Gmail and my works Exchange
2010 server.

Gmail is great! :-D But I don't have so much mail in there.

Exchange not so :`(

Without the Gnus agent on when fetching my largish Inbox on Exchange I
have found that I can happily enter the Inbox file from the group buffer
if I request 4265 articles (C-u SPACE 4265 or gnus-group-read-group).

If I request 4266 articles then Gnus reports "No unread news" and moves
the cursor to the bottom of the buffer.

In both cases the total number of available articles is reported
correctly.

I can get the data though if I jump into the buffer and then run "/ o"
or gnus-summary-insert-old-articles.  Interestingly this function
returns not the number of messages but what looks like the max article
UID in the prompt (bug or feature?).

Switching on debugging (via nnimap-record-commands t) shows a
spectacularly big fetch line for gnus-group-read-group when asking for
everything.  I'm wondering if the request is too large based on this
rather flimsy evidence...to say the UIDs are not contiguous is an
understatement.  How does this code work?  Are requests split into
sensible chunks?

Interestingly the gnus-summary-insert-old-articles command doesn't log
any activity in *imap log* so that's probably a bug in itself but also
hints something is going on quite different.

I replicated this on two different machines...

If you grow your mailbox slowly and use Gnus agent then you don't hit
any issues as it kicks in when you request everything...

Anyone seen anything similar or have thoughts how I might get around
this?

Phew!

-- 
Matt