From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/81930 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.gnus.general Subject: Re: Excessive nntp reads since today Date: Wed, 13 Jun 2012 17:18:21 +0200 Message-ID: <87haufw88y.fsf@thinkpad.tsdh.de> References: <877gvcd91f.fsf@thinkpad.tsdh.de> <85txygk74a.fsf@iznogoud.viz> <87y5nsbqj4.fsf@thinkpad.tsdh.de> <85pq94k37p.fsf@iznogoud.viz> <87aa08big2.fsf@thinkpad.tsdh.de> <85vcivuxmf.fsf@iznogoud.viz> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1339600768 12125 80.91.229.3 (13 Jun 2012 15:19:28 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 13 Jun 2012 15:19:28 +0000 (UTC) Cc: Lars Magne Ingebrigtsen To: ding@gnus.org Original-X-From: ding-owner+M30200@lists.math.uh.edu Wed Jun 13 17:19:27 2012 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SepLw-0003Ke-DH for ding-account@gmane.org; Wed, 13 Jun 2012 17:19:24 +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 1SepL9-0008Fn-UV; Wed, 13 Jun 2012 10:18:35 -0500 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1SepL7-0008FY-6F for ding@lists.math.uh.edu; Wed, 13 Jun 2012 10:18:33 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1SepL5-00085l-Qi for ding@lists.math.uh.edu; Wed, 13 Jun 2012 10:18:32 -0500 Original-Received: from deliver.uni-koblenz.de ([141.26.64.15]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1SepL3-0003SJ-Iv; Wed, 13 Jun 2012 17:18:29 +0200 Original-Received: from localhost (localhost [127.0.0.1]) by deliver.uni-koblenz.de (Postfix) with ESMTP id 21D4DD23AC; Wed, 13 Jun 2012 17:18:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at uni-koblenz.de Original-Received: from deliver.uni-koblenz.de ([127.0.0.1]) by localhost (deliver.uni-koblenz.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVDlK6NV6zlS; Wed, 13 Jun 2012 17:18:28 +0200 (CEST) X-CHKRCPT: Envelopesender noch tassilo@member.fsf.org Original-Received: from thinkpad.tsdh.de (tsdh.uni-koblenz.de [141.26.67.142]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTPSA id 66D95D23B1; Wed, 13 Jun 2012 17:18:28 +0200 (CEST) In-Reply-To: <85vcivuxmf.fsf@iznogoud.viz> (Wolfgang Jenkner's message of "Wed, 13 Jun 2012 15:48:04 +0200") User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.1 (gnu/linux) X-Spam-Score: -4.9 (----) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:81930 Archived-At: Wolfgang Jenkner writes: Hi Wolfgang, >> - The old and buggy 'some semantics of `gnus-fetch-old-headers' >> were exactly what I want. I.e., I want Gnus to *fetch* only new >> messages, but it should also *display* summary lines of old >> messages to fill loose threads in case those can be determined from >> the overview. > > IIUC, the summary would consist of new headers and some subset of the > headers cached by the agent. Yes, exactly. > I think this is a problem because the agent cache seems to be designed > to be transparently used, so that you have always the illusion of > talking directly to the server. When the agent is plugged, that is. > However, when the agent is unplugged, the agent is your server, in > some sense. So I think you can have what you want in the following > clean way: > > Get new articles, fetch them with the agent, unplug, enter a group. > > g J s J j . RET Yes, that would probably work. However, that would be extremely inconvenient. And as soon as I forget to unplug the agent when entering a group, the agent would see that my .overview files start with article 382832 instead of 1 and start downloading the headers of the old 382831 ones. That's simply not feasible for large groups, e.g., all the emacs and gnus groups on gmane which are never expired and thus contain millions of articles. > For this to work, it seems necessary to set gnus-fetch-old-headers to > t instead of some (but I might have wrong expectations or > misunderstand something here, and, obviously, I haven't tested this > very extensively). I think t and 'some are the same with respect to the agent. And it gets the value only as parameter but never accesses the variable directly. Lars, what do you think? IMHO, the best cure is to remove `gnus-fetch-old-headers' altogether and add a `gnus-summary-show-old-articles' variable that only deals with the summary display stuff. Values would be t (show all), nil (only unread), or 'some (some old to connect lose threads), or a number (show unread + N old). How many old articles are fetched at most in the `A T' case is handled by `gnus-refer-thread-limit' anyway. I'm not sure if C-u 1000 RET on a group would still fetch (- 1000 |cached| |unread|) old articles, though... The only difference to the current state of affairs would be that t or 'some for `gnus-summary-show-old-articles' would only show already fetched articles. Thus, when subscribing to some new group, catching up, getting new news again, entering the group, you'd possibly have unconnected articles initially, but that would go away over time when the overview files get filled unless very old messages are referenced. Of course, all of this requires a nil `gnus-nov-is-evil', but that has always been the case, right? And I think it would be equivalent to the old behavior before your commit, except that the documentation and the name of the variable would actually match the behavior. :-) Bye, Tassilo