From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/70366 Path: news.gmane.org!not-for-mail From: David Engster Newsgroups: gmane.emacs.gnus.general Subject: Re: Faster, lolcat. Faster! Date: Thu, 02 Sep 2010 16:39:11 +0200 Message-ID: References: <87aao05t55.fsf@lifelogs.com> <87bp8gflj5.fsf@keller.adm.naquadah.org> <87pqwwgyjb.fsf@mid.gehheimdienst.de> <874oe85l97.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1283438380 3584 80.91.229.12 (2 Sep 2010 14:39:40 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 2 Sep 2010 14:39:40 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M18750@lists.math.uh.edu Thu Sep 02 16:39:39 2010 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OrAwz-0006FT-Te for ding-account@gmane.org; Thu, 02 Sep 2010 16:39:38 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1OrAwu-0000v9-JV; Thu, 02 Sep 2010 09:39:32 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OrAwt-0000ut-AT for ding@lists.math.uh.edu; Thu, 02 Sep 2010 09:39:31 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1OrAwo-0000n7-7N for ding@lists.math.uh.edu; Thu, 02 Sep 2010 09:39:31 -0500 Original-Received: from m61s02.vlinux.de ([83.151.21.164]) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1OrAwn-000688-00 for ; Thu, 02 Sep 2010 16:39:25 +0200 Original-Received: from [134.76.4.238] (helo=imac.local) by m61s02.vlinux.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1OrAwm-0004xx-IW for ding@gnus.org; Thu, 02 Sep 2010 16:39:24 +0200 In-Reply-To: (Lars Magne Ingebrigtsen's message of "Thu, 02 Sep 2010 16:23:00 +0200") User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (darwin) Mail-Copies-To: never Mail-Followup-To: ding@gnus.org X-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:70366 Archived-At: Lars Magne Ingebrigtsen writes: > Ted Zlatanov writes: > >> DE> http://article.gmane.org/gmane.emacs.gnus.general/67238 >> ... >> DE> The complicated part is to use this function in the general Gnus back >> DE> end. It's pretty scary down there. >> >> Yeah, that's why I brought it up. If Lars can't figure it out I may >> have to look at that code, and then dark gods will drag me down to the >> bottom of the ocean (as seen in Disney's "Little Mermaid 7: Call of Cthulhu"). > > Heh heh. > > I think `*-request-group-articles' would work for all backends where it > makes sense, and imap is probably one of them. I think. Or does it? > > I mean, the main problem is that Gnus thinks that there are, say 55 > unread articles, and the article range is 200-300. Even if you have the > -group-articles command return something that says "the range is > 200-300, but there are only 75 actual articles in that range", then it > doesn't really help. You don't know which of the 55 articles Gnus > thinks are unread are still on the server. > > So the server would have to return > > ((200 . 210) 215 (245 . 276)) > > or something, and then Gnus could figure it all out. Yes, exactly. The nnimap-request-group-articles I posted simply returns the list of available article numbers in that group (which could be further compressed into the above range notation). Requesting the range of articles can take a second for very large groups, so some kind of caching should be done. Anyway, this would be an optional back end function, and Gnus can query the back end for availability and use it (if the user wants it). I for example don't have much problems with the article count, but I don't delete much and use Dovecot. But there are IMAP servers out there (Zimbra...) which use absolutely insane values for article numbers; maybe it's using those for Mersenne prime searching or something. -David