searching by Message-ID after copy/move; speeding things up

[Michael Welsh Duggan <md5i@md5i.com>]

When moving or adding an article to an IMAP group, Gnus takes note of
the UID of the message that has been added to the new group.  Using most
modern IMAP servers, getting this value is as simple as looking for a
COPYUID or APPENDUID response after the copy/append.

Some servers don't support COPYUID or APPENDUID, however, and on those
servers we have to do a little more work to figure out the new message
UID.  This is done using the nnimap-find-article-by-message-id
function.  This function executes a UID SEARCH HEADER Message-ID command
in order to get the article UID.  This works, but...

When working with an IMAP server that doesn't include Message-ID headers
in its index, finding the article ends up mapping to looking at every
single article in the group.  This can be slow, and gets slower as the
group gets larger.  Now, any modern IMAP server should not have this
problem.  Unfortunately there is at least on very popular server that
_does_ exhibit this problem: Microsoft Exchange.

Like many, I use Gnus to connect to a company run Exchange server
because that is my substitute for using the POS that is Microsoft
Outlook.  (That, and why would I _not_ be using Emacs?)  However, this
slowness on article moving problem has been a bit of a thorn in my
backside.  The first message I move to a particular group on any one day
can cause a delay of up to 1.5 minutes or longer.  And that is very,
very annoying.

So, I solved this problem in my own copy of Gnus.  I could easily post
the diffs here.  Unfortunately, my place of work refuses to give a
blanket disclaimer for a program (such as Gnus or Emacs) and will
instead only hand out case-by-case disclaimers (that are very irritating
to get).  And my patch goes a little over the 10 line "small change"
boundary.  As such, in the hopes that such a feature might make it into
Gnus mainline, I am instead going to explain a solution such that
someone else who is motivated could easily recreate something similar to
my implementation.

The idea is simple enough.  I added an extra optional argument to
nnimap-find-article-by-message-id which would be set when looking for
articles that have been _recently_ appended to a group.  Then if the
optional argument is set, I do a range-limited UID search limited to the
last N articles in the group.  If this fails, I revert to the
non-limited search.  I have a user option which represents the number of
articles to look through, with nil reverting back to the original
behavior.  I set the optional argument to t when called from the move or
append functions.

The change was quite simple, and most of my time was spent re-learning
how the nnimap library does things in general.  I hope that something
like this can make it into mainline Gnus.

-- 
Michael Welsh Duggan
(md5i@md5i.com)