From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/28908 Path: main.gmane.org!not-for-mail From: Karl Kleinpaste Newsgroups: gmane.emacs.gnus.general Subject: Re: Pterodactly gripe / oGnus wish Date: 21 Jan 2000 12:46:55 -0500 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=us-ascii X-Trace: main.gmane.org 1035165671 32261 80.91.224.250 (21 Oct 2002 02:01:11 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 02:01:11 +0000 (UTC) Keywords: gnus,articles,group,time,data,number,ticked,query,large Return-Path: Original-Received: from bart.math.uh.edu (bart.math.uh.edu [129.7.128.48]) by mailhost.sclp.com (Postfix) with ESMTP id C2B2BD051E for ; Fri, 21 Jan 2000 12:50:56 -0500 (EST) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by bart.math.uh.edu (8.9.1/8.9.1) with ESMTP id LAB18932; Fri, 21 Jan 2000 11:49:32 -0600 (CST) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Fri, 21 Jan 2000 11:47:14 -0600 (CST) Original-Received: from mailhost.sclp.com (postfix@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id LAA06273 for ; Fri, 21 Jan 2000 11:47:03 -0600 (CST) Original-Received: from beaver.jprc.com (BEAVER.JPRC.COM [207.86.147.217]) by mailhost.sclp.com (Postfix) with ESMTP id 1A0BBD051E for ; Fri, 21 Jan 2000 12:46:56 -0500 (EST) Original-Received: (from karl@localhost) by beaver.jprc.com (8.9.3/8.9.3) id MAA13561; Fri, 21 Jan 2000 12:46:55 -0500 X-Authentication-Warning: beaver.jprc.com: karl set sender to karl@justresearch.com using -f Original-To: ding@gnus.org X-Face: "5(T0tZd{6}pd~YzBG8O/*EW,.]6]@`m^e;fv65W^Y&=d"M\1H}>T~4_.kcDD.O~y3k)a6h R;Nmi>9|>Nm${2IpM0^RcUEa\jcq?KOP)C&~x51l~zCHTulL^_T|u0I^kB'z@]{`2YjQu In-Reply-To: sperber@informatik.uni-tuebingen.de's message of "21 Jan 2000 18:24:42 +0100" Original-Lines: 44 User-Agent: Gnus/5.0804 (Gnus v5.8.4) XEmacs/21.2 (Hera) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:28908 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:28908 sperber@informatik.uni-tuebingen.de writes: > But the number in *Group* is *right*. The number it prompts me with > is wrong. Why? Because it has reason to want to offer you other articles besides just those few that are ticked. It has an (unreal) large set of articles to offer you. If you have, say, 3 articles ticked, and yet you have a group with 350 articles available, it will still query. If all that remains in the group is the set of 3 ticked articles, then Gnus should not be querying you. *That* much, Gnus knows, but only because it's additional state which Gnus has stored in .newsrc.eld. > And why can't Gnus look up the relevant information when constructing > the *Group* buffer? At the latest, it should look it up when it > prompts me for a number. There's something fundamental I'm not > getting here, or there's a fundamental design flaw in Gnus. The whole point of the query is to ask if you really want Gnus to commit to spending all that time, constructing all that information, for some apparently-but-unreal very large set of articles. Try an experiment: Simply set gnus-large-newsgroup to some astronomical number. 100000 or so. Then experiment with group entry, see what happens. The point here is this: Gnus believes there's some large set of articles. The time when Gnus learns whether this is a real estimate occurs *after* Gnus has committed itself to retrieving potentially hundreds or thousands of articles' worth of overview data. That will occupy a lot of time over a slow link, and will make Gnus spend a lot of time computing a *Summary* buffer. Once Gnus has begun retrieving the information about what articles actually exist, you can't stop it. It's a synchronous process. What I'm getting at is that you can't say "look it up, then ask me," because it is the very process of looking it up that the query is trying to stop. "Looking it up" is the expensive activity in question. > Well, OK. But why does Gnus have to get unbearably slow when dealing > with these gaps? This is really the worst aspect of the problem. That's a very good question, and one which I can't answer. But personally, I don't notice this slowdown in the first place.