Simon Josefsson writes:

> Please send them to the list, I'd be interested in understanding how
> you implement it.

OK, here it is.  But it is still not suitable for public consumption...  

To workaround Emacs' limitation on integers size, I map IMAP's UIDs to
article numbers, starting at 1, then incrementing as new UIDs are
discovered.  UIDs are kept as strings while article numbers are Emacs
integers.  The function that builds this mapping is
`nnimap-update-uid-map'.  I'm still not sure where it should be called
and you'll have to insert a call to it somewhere in your sources.  For
the moment I have put it near the top of
`nnimap-request-update-info-internal' and it seems ok here.  If you
know more about this, tell me.

Also, you have to manually trigger the use of this numbering scheme,
otherwise it will not be used.  The reasons for this are:

    1. This is pre-alpha quality implementation that may (will) loose
       your mails,

    2. Going from traditional integer UIDs to string UIDs will wreck
       all your flag settings, cache and surely more things...

Now that you have been warned, if you still want to set it to work,
you have to add a (msg-high . 0) parameter to the nnimap group that
will use the string UIDs.  That is, in the *Group* buffer, with point
on the nnimap group, do "G E" (M-x gnus-group-edit-group) and make it
look something like:

    ("nnimap+imap:INBOX" 3 nil nil
     (nnimap "imap")
     ((msg-high . 0)))

Then cross fingers and update the group and enter it and read it...  A
sign that it is working is that another new parameter will be added to
all nimap groups with the mapping from article number to UID.  Even in
groups which don't use it.  Only groups with the `msg-high' parameter
will use the new numbering scheme.

I'd be pleased to discuss issues regarding this scheme.

Kim Minh.