0.126, xemacs, pgnus-0.95, and really large UIDs

[Michael Poole <poole@graviton.subatomic.org>]

Having recently upgraded from XEmacs-20.4 with its Gnus and a very old (John
Prevost era) nnimap to XEmacs-21.1.4 with pgnus-0.95 and nnimap-0.126, I note
a few things different.

One (easy to remedy) is that LIST is hardcoded as the method to use to
retrieve a folder list with.  On the server I am trying to use, there are
some ten thousand or more folders, and I have to traverse the Internet at
large to talk to it.  Listing all 10k+ folders is not something I want to
do; neither are the subsets I want to read in any particular parts of the
folder hierarchy -- so I cannot use the nnimap-list-pattern method to
select those.

The more difficult problem is that the server likes to use the full range
of UID values.  Even with XEmacs-21 configured to use minimal tagbits, it
still occasionally overflows the reader.  Besides not being able to read
the particular folder with a too-great UID value, nnimap does not finish
opening the server -- so I cannot see *any* folders in the server.

The server is
(nnimap "cyrus"
	(nnimap-address "cyrus.andrew.cmu.edu")
	(nnimap-stream kerberos4)
	(nnimap-authenticator kerberos4)
	(nnimap-expunge-on-close ask))
and when I go to open the server in the *Server* buffer, it says:
"nnimap: Generating active list for cyrus..." and eventually stops doing
anything.  If I hit C-g to interrupt it, I get a warning:

(1) (error/warning) Error in process filter:
  (invalid-read-syntax Integer constant overflow in reader 2003395529 10)

and in the IMAP log I see:

 283 EXAMINE "andrew.contributed"
 * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
 * OK [PERMANENTFLAGS (\Seen)] 
 * 5 EXISTS
 * 0 RECENT
 * OK [UNSEEN 3] 
 * OK [UIDVALIDITY 832448743] 
 283 OK [READ-ONLY] Completed
 284 FETCH 1,* UID
 * 1 FETCH (UID 2003395529)
 * 5 FETCH (UID 2003395970)
 284 OK Completed

RFC 2060 says (in section 2.3.1.1) that the UID is a 32-bit value (it does
not specify signedness), so the Cyrus server is justified in using that
UID.  While I don't think this is going to be easy to fix, the fact that
an out-of-range UID (and perhaps UIDVALIDITY as well) could stop me from
reading *any* groups is fairly hampering.

(As a side note, the older nnimap handled this by making UIDs a cons of
two integers, each containing part of the UID.  It also broke in several
ways I've been unable to completely figure out due to changes in how
XEmacs behaves -- one such being concat no longer accepting integer
arguments.)

I'm not terribly familiar with the nnimap code, so I don't have a patch
myself; I'm willing to test somebody else's patches, or to try to make my
own if someone will point me in the right general direction to fix these.

-- Michael