Fixed a bug in nnimap-0.37

[Matt Armstrong <mattdav+matt@best.com>]

Recently I've noticed that my tick marks (!) have been slowly
vanishing.  I typically have between 5-20 messages in each group
ticked so I can deal with them later.  Losing my tick marks tends to
make me look bad -- it is essentially my to-do list.

I can reproduce the bug easily.  Enter a group, read all the messages,
tick 5 messages with !, leave the group.  Then enter and leave the
group five times.

Expected: each time you enter, your five messages show up, all ticked.

Observed: each time you enter, one less ticked message shows up.

I tracked it down to a bug in nnimap-retrieve-headers and the
processing of the FETCH-OLD arg.

If the passed ARTICLES is (250 251 252) and the passed FETCH-OLD is
1000, the sequence was getting set to (-750 251 252) -- obviously
wrong.

Example UID FETCH lines this bug produced:

A186 UID FETCH -619,382 (UID RFC822.HEADER RFC822.SIZE BODY)
A196 UID FETCH -723,278 (UID RFC822.HEADER RFC822.SIZE BODY)
A214 UID FETCH -724,277:278 (UID RFC822.HEADER RFC822.SIZE BODY)

I tried using 'min' to clip the sequence to (1 251 252), but the code
then fetched UIDs 1, 251 and 252 -- skipping 250.  E.g.

A256 UID FETCH 1,382 (UID RFC822.HEADER RFC822.SIZE BODY)  <- should be 1:382 ?
A266 UID FETCH 1,379:382 (UID RFC822.HEADER RFC822.SIZE BODY) <- maybe 1:382 ?

Again, in this case, nnimap would clear the \Flagged flag the IMAP
server for UID 250 at group exit.

At this point, I pronounced support for FETCH-OLD a "burden" and, wow,
the Gnus manual says you can ignore FETCH-OLD if this is the case.
This fixed it.  I was seeing a FETCH-OLD value of 1000, which would be
really slow over my modem link anyway, so it is probably best ignored
by design.


--- nnimap.el.orig      Wed Oct 28 17:58:06 1998
+++ nnimap.el   Wed Oct 28 17:58:14 1998
@@ -351,10 +351,8 @@
 (deffoo nnimap-retrieve-headers (articles &optional group server fetch-old)
   (when (nnimap-possibly-change-group group server)
     (with-current-buffer nntp-server-buffer (erase-buffer))
-    (let* (compressed (uncompressed (gnus-uncompress-sequence articles)))
-      (when (numberp fetch-old)
-        (setcar uncompressed (- (car uncompressed) fetch-old)))
-      (setq compressed (gnus-compress-sequence uncompressed t))
+    (let* ((uncompressed (gnus-uncompress-sequence articles))
+          (compressed (gnus-compress-sequence uncompressed t)))
       (with-current-buffer nnimap-server-buffer
        ;; Reset message info, this makes sure we return 423 on
        ;; articles that were removed by another client while we
--- ChangeLog~  Tue Oct 20 04:26:35 1998
+++ ChangeLog   Wed Oct 28 17:59:54 1998
@@ -1,3 +1,7 @@
+1998-10-28  Matt Armstrong  <matta@geoworks.com>
+
+       * nnimap.el (nnimap-retrieve-headers): ignore fetch-old arg.
+
 1998-10-20 14:21:00  Simon Josefsson  <jas@pdc.kth.se>

        * nnimap 0.37 released.



P.S. This exacerbates a fear I have about how the way nnimap maintains
the marks on the IMAP server.  Maybe the backend should keep a
"dribble file" of all the (hopefully user requested) mark changes made
while the group is open and use that at group close time to write out
IMAP marks?

-- 
matta