From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/37389 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.general Subject: Re: `new' indicator for nnimap groups? Date: Thu, 2 Aug 2001 17:32:33 +0200 (CEST) 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 1035172814 13651 80.91.224.250 (21 Oct 2002 04:00:14 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 04:00:14 +0000 (UTC) Cc: Return-Path: Return-Path: Original-Received: (qmail 4816 invoked from network); 2 Aug 2001 15:32:37 -0000 Original-Received: from lie.extundo.com (195.42.214.244) by gnus.org with SMTP; 2 Aug 2001 15:32:37 -0000 Original-Received: from localhost (jas@localhost) by lie.extundo.com (8.11.2/8.11.2) with ESMTP id f72FWXh19920; Thu, 2 Aug 2001 17:32:33 +0200 X-Authentication-Warning: lie.extundo.com: jas owned process doing -bs Original-To: Kai =?iso-8859-1?q?Gro=DFjohann?= In-Reply-To: Original-Lines: 28 Xref: main.gmane.org gmane.emacs.gnus.general:37389 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:37389 On Thu, 2 Aug 2001, Kai Großjohann wrote: > On Thu, 2 Aug 2001, Simon Josefsson wrote: > > > Hmm. Ah, yes, I meant the active range. If you only have the > > currently highest/lowest article number, and get an updated count of > > articles in the mailbox, how do you know which articles exists in > > the mailbox? So Gnus doesn't know which articles to request from > > the backend when entering the group, unless it knows the > > highest/lowest article number. But still, this decision could be > > delayed from `g' to when you actually enter the group to speed > > things up. The backend interface probably needs to change for this, > > though. > > My suggest was to change the backend interface in such a way that some > backends report the number of unread messages _in addition to_ the > low/high numbers. The rest of Gnus can continue to use the low/high > numbers as before, only the `draw the group buffer' code uses the > number of unread messages (if available). > > I fail to see how Gnus could work less well when it has more > information? Ah, I thought we we're talking about how to optimize away the unnecessary (re-)selecting of mailboxes to get the \Recent flag to be useful. To get that to work, we can't have the old system still in place. But yes, it could be done in steps.