From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/25535 Path: main.gmane.org!not-for-mail From: Guido Van Hoecke Newsgroups: gmane.emacs.gnus.general Subject: Re: B m completion Date: 29 Sep 1999 16:13:35 +0200 Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1035162902 14447 80.91.224.250 (21 Oct 2002 01:15:02 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 01:15:02 +0000 (UTC) Cc: Gnus mailing list , nnimap mailing list Return-Path: Original-Received: from spinoza.math.uh.edu (spinoza.math.uh.edu [129.7.128.18]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id KAA29689 for ; Wed, 29 Sep 1999 10:20:33 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by spinoza.math.uh.edu (8.9.1/8.9.1) with ESMTP id JAB10948; Wed, 29 Sep 1999 09:16:37 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Wed, 29 Sep 1999 09:17:09 -0500 (CDT) Original-Received: from sclp3.sclp.com (root@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id JAA21585 for ; Wed, 29 Sep 1999 09:16:59 -0500 (CDT) Original-Received: from btm4r4.alcatel.be (btm4r4.alcatel.be [195.207.101.110]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id KAA29641 for ; Wed, 29 Sep 1999 10:14:52 -0400 (EDT) Original-Received: from btm16s.se.bel.alcatel.be (root@btm16s.se.bel.alcatel.be [138.203.33.210]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with ESMTP id QAA22463 for ; Wed, 29 Sep 1999 16:14:18 +0200 (MET DST) Original-Received: from BTM4BZ.se.bel.alcatel.be (btm4bz [138.203.34.132]) by btm16s.se.bel.alcatel.be (8.8.8+Sun/8.8.8+SUN) with ESMTP id QAA28497; Wed, 29 Sep 1999 16:14:10 +0200 (MET DST) Original-To: Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai =?iso-8859-1?q?Gro=DFjohann?=) In-Reply-To: Kai.Grossjohann@CS.Uni-Dortmund.DE's message of "29 Sep 1999 12:13:30 +0200" Original-Lines: 46 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) Emacs/20.4 Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:25535 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:25535 Kai Großjohann writes: > Guido Van Hoecke writes: > > > However, the drawback is that nnimap/gnus queries my imap server for > > new mail in each of these folders. This is time consuming and > > completely useless: I never have any mail delivered to any of these > > folders. > > Sometimes, nnimap says `checking group foo' for all groups. This is > really fast. At other times, it says `updating info for group foo' > for all groups. This is really slow. If you see the latter, I think > it would be best for you to make it so that nnimap says `checking' > instead. I think you will observe an order of magnitude in speed > increase, much more than could be achieved otherwise. Yes, I have now observed this, and indeed the difference is an order of magnitude. I used to call (gnus 5). Now I just call (gnus) and the initial phase uses 'checking...' rather than 'updating...'. Boy this is fast. However, no matter what I do, the next time around, e.g. by keing 'g' in the group buffer, or M-x gnus again, it always reverts to 'updating...' > > I'm not sure what needs to be done to make it so, but I think the > problem is the select method. I have (manually!) set the select method > of all my nnimap groups to "nnimap:" (no parentheses!), and this > seemed to work well. Maybe you need "nnimap+foo:", though. I have manually edited my select method, and set them to "nnimap:se" for all my imap groups. But this does not make any difference. > > And I find that nnimap switches from `checking' to `updating info' > when doing M-x gnus-no-server RET as well as when invoking M-x gnus > RET with a specific level. Oh, well. > > But maybe this discussion should be in the nnimap list... Even if somebody can help me with a mechanism to stick to the 'checking' method, I still would like to be able to define that some groups never need a 'get-new-mail': such a group parameter would still provide a faster method than the 'checking' approach. Guido.