[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problems with latest imap stuff
Matt Armstrong <mattdav+matt@best.com> writes:
> nnimap almost works for me now (nnimap-0.32, pgnus-0.34 plus the fix
> to gnus-remove-from-range).
Good to hear! I know there are several problems in nnimap that makes
it unusable for many people (Uwash servers come to mind).
(On the other hand, I'm now reading all my mail, kerberos
authenticated, with nnimap so at least it can work correctly for
some.)
> When I read a message, they get marked as 'seen' on the server. The
> imap server sticks a "Status: 0" flag header in each message.
This is server-internal stuff and it doesn't say much to me, perhaps
it will to the server-authors.
> A181 SELECT IMAP/monty
> * 100 EXISTSj
> * OK [UIDVALIDITY 907577819] UID validity status
> * FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
> * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Draft \Seen)]
> * 1 RECENT
> A181 OK [READ-WRITE] SELECT completed
> A182 UID STORE 3 -FLAGS (\Flagged)
> * 3 FETCH (FLAGS (\Seen) UID 3)
> A182 OK UID STORE completed
> A183 UID STORE 99:100 +FLAGS (\Seen)
> * 99 FETCH (FLAGS (\Seen) UID 99)
> * 100 FETCH (FLAGS (\Recent \Seen) UID 100)
> A184 CLOSE
> A184 OK CLOSE completed
> A185 SELECT IMAP/monty
> * 100 EXISTS
> * OK [UIDVALIDITY 907577819] UID validity status
> * FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
> * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Draft \Seen)]
> * 1 RECENT
> A185 OK [READ-WRITE] SELECT completed
> A186 UID SEARCH UNSEEN UNDELETED
> * SEARCH 99 100
> A186 OK UID SEARCH completed
I can't believe this to be anything but a bug -- the UID STORE returns
OK and we're told what the new flags of the message is and they are as
nnimap wanted them to be. The UNSEEN UNDELETED search result is plain
wrong.
I'd suggest sending this snippet, along with the "Status" fields in
the message to the server authors.
> I don't have this problem with Netscape.
It probably only searches for "positive" matches (read articles)
instead of searching for both unread and read articles as nnimap does
(for some historical reasons, it's in the mailing list archive).
Try this patch I'm trying out for 0.33 which abolish all that stuff.
Let me know if you see any ill-effects of this, I know the
unread-count in the group buffer can get funny, but it's just a
estimate and one shouldn't trust it anyway.
Index: nnimap.el
===================================================================
RCS file: /home/radford/src/cvs/nnimap/nnimap.el,v
retrieving revision 1.77
diff -u -w -r1.77 nnimap.el
--- nnimap.el 1998/10/10 19:48:56 1.77
+++ nnimap.el 1998/10/13 22:02:24
@@ -739,25 +739,7 @@
(when (nnimap-mark-permanent-p 'read)
(gnus-info-set-read
info
- ;; xxx This is extremely slow.
- (let* (
- ;; oldseen could contain articles marked unread by other
- ;; imap clients! we correct this
- (oldseentmp (gnus-uncompress-range (gnus-info-read info)))
- (unseen (imap-search "UNSEEN UNDELETED"))
- (oldseen (gnus-set-difference oldseentmp unseen))
- ;; oldseen might lack articles marked as read by other
- ;; imap clients! we correct this
- (newseen (imap-search "SEEN"))
- ;; ok, read articles are in oldseen+newseen (xxx lots of dupes)
- (seen (append oldseen newseen))
- ;; sort to have gnus-compress-sequence remove dupes
- (seens (sort seen '<))
- (read (gnus-compress-sequence seens t)))
- (if (and read
- (atom (car read)))
- (list (cons (car read) (car read))) ;; xxx not my bug
- read))))
+ (gnus-compress-sequence (imap-search "SEEN") t)))
(mapc (lambda (pred)
(when (and (nnimap-mark-permanent-p (cdr pred))
> In fact, once I visit the folder with Netscape and read the
> messages, they are marked with a "Status: RO" header on the server
> and Gnus no longer shows them as unread. I'm not sure what IMAP
> flag gets associated with 'R' or why Netscape is setting it.
This is more strange. Hm. I bet netscape read articles by fetching
them without PEEK, and this set the \Seen mark implicitely. Try the
patch below and see if the server now remembers which articles you've
read.
Until your server gets fixed, you could run this patch -- but beware
that the flag stuff will be a little bit flakier. Actually the only
problem you should be seeing is that marking a article you've just
read as unread won't work unless you quit the summary buffer and enter
it again. No biggie, but it's wrong anyway.
--- nnimap.el- Wed Oct 14 00:05:13 1998
+++ nnimap.el Wed Oct 14 00:05:33 1998
@@ -508,7 +508,7 @@
(nnoo-status-message 'nnimap server))))))
(deffoo nnimap-request-article (article &optional group server to-buffer)
- (nnimap-request-article-part 'RFC822 article group server to-buffer t))
+ (nnimap-request-article-part 'RFC822 article group server to-buffer nil))
(deffoo nnimap-request-head (article &optional group server to-buffer)
(nnimap-request-article-part 'RFC822.HEADER article group server to-buffer))
(deffoo nnimap-request-body (article &optional group server to-buffer)