Gnus development mailing list
 help / color / mirror / Atom feed
From: David Engster <deng@randomsample.de>
To: ding@gnus.org
Subject: Snappy low-bandwidth nnimap, part II
Date: Sun, 26 May 2013 16:28:03 +0200	[thread overview]
Message-ID: <87li71x1cc.fsf@randomsample.de> (raw)

[-- Attachment #1: Type: text/plain, Size: 1467 bytes --]

Last year I started the following thread:

http://thread.gmane.org/gmane.emacs.gnus.general/82121

In a nutshell: I was on vacation with a horrible mobile connection, and
nnimap kept doing those 'initial syncs', downloading hundreds of
kb. Nobody really knew what was going on, Lars only mentioned that it
was probably due to 'unexist' handling.

Since I'm doing my vacation at the same place this year, I just had to
debug this. Turns out it is indeed due to unexist handling using
QRESYNC. The problem seems to be this:

Say you have a group 'ding' and you refresh it on a QRESYNC-enabled
server. Gnus will look at the VANISHED answer and mark those articles as
'unexist'. However, if the group does not have any vanished articles,
the group's info will just contain '(unexist)' in its marks (hit 'G E'
to see it).

Now, when you enter this group and simply exit it again, you'll see that
this '(unexist)' range was deleted, which kinda makes sense because,
well, its an empty range, so why keep it? The problem is just that
nnimap-retrieve-group-data-early will now think this group was not
synced before and retrieve *all* flags instead of just the last 100,
which is what this 'doing initial sync' really means.

So the fix is pretty simple: Keep empty unexist ranges in the group's
info. The attached patch does that, but I'm not sure if this really is
the best solution, or if maybe this shouldn't be better fixed in
nnimap-retrieve-group-data-early?

-David


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: unexist-patch.diff --]
[-- Type: text/x-diff, Size: 452 bytes --]

diff --git a/lisp/gnus-sum.el b/lisp/gnus-sum.el
index aaed1d1..cab303d 100644
--- a/lisp/gnus-sum.el
+++ b/lisp/gnus-sum.el
@@ -6067,7 +6067,8 @@ If SELECT-ARTICLES, only select those articles from GROUP."
 			 (gnus-active gnus-newsgroup-name) del))
 	      (push (list del 'del (list (cdr type))) delta-marks))))
 
-	(when list
+	(when (or list
+		  (eq (cdr type) 'unexist))
 	  (push (cons (cdr type) list) newmarked)))
 
       (when delta-marks

             reply	other threads:[~2013-05-26 14:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-26 14:28 David Engster [this message]
2013-06-05 16:46 ` David Engster
2013-06-06 14:36   ` Ted Zlatanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87li71x1cc.fsf@randomsample.de \
    --to=deng@randomsample.de \
    --cc=ding@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).