* Excessive nntp reads since today @ 2012-06-12 12:11 Tassilo Horn 2012-06-12 13:11 ` Wolfgang Jenkner 0 siblings, 1 reply; 19+ messages in thread From: Tassilo Horn @ 2012-06-12 12:11 UTC (permalink / raw) To: ding; +Cc: wjenkner Hi all, since I've updated Ma Gnus today, when I want to enter some nntp group with, say, 3 unread articles, it'll start downloading the whole internet. Well, seriously, it'll frequently download twenty or more MB. My `gnus-fetch-old-headers' is 'some, so it might want to fetch some older messages to connect new articles in a thread, but not so many. I just entered the gmane xetex group which had 4 new articles. The summary showed those 4 articles + 2 old articles from yesterday (the 4 new were replies of the 2 old ones). But when entering the group, the "nntp read: <x> kb" message counted to more than 12.000. I suspect this change is the culprit, so I added Wolfgang to the Cc. ,---- | commit 44f603535c63aab124e139b145fce20fff488f38 | Author: Wolfgang Jenkner <wjenkner@inode.at> | Date: Mon Jun 11 23:49:17 2012 +0200 | | Make `A T' work when agentized | | * gnus-agent.el (gnus-agent-retrieve-headers): Recalculate the range of | articles when fetch-old is non-nil (bug#11370). `---- Bye, Tassilo ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Excessive nntp reads since today 2012-06-12 12:11 Excessive nntp reads since today Tassilo Horn @ 2012-06-12 13:11 ` Wolfgang Jenkner 2012-06-12 13:36 ` Tassilo Horn 0 siblings, 1 reply; 19+ messages in thread From: Wolfgang Jenkner @ 2012-06-12 13:11 UTC (permalink / raw) To: Tassilo Horn; +Cc: ding On Tue, Jun 12 2012, Tassilo Horn wrote: > My `gnus-fetch-old-headers' is 'some, so it might want to fetch some > older messages to connect new articles in a thread, but not so many. I > just entered the gmane xetex group which had 4 new articles. The > summary showed those 4 articles + 2 old articles from yesterday (the 4 > new were replies of the 2 old ones). But when entering the group, the > "nntp read: <x> kb" message counted to more than 12.000. > > I suspect this change is the culprit, so I added Wolfgang to the Cc. > > ,---- > | commit 44f603535c63aab124e139b145fce20fff488f38 > | Author: Wolfgang Jenkner <wjenkner@inode.at> > | Date: Mon Jun 11 23:49:17 2012 +0200 > | > | Make `A T' work when agentized > | > | * gnus-agent.el (gnus-agent-retrieve-headers): Recalculate the range of > | articles when fetch-old is non-nil (bug#11370). > `---- I admit that it hadn't occurred to me to test this patch with non-default values of gnus-fetch-old-headers, but the docstring of this variable actually seems to match the behaviour you describe... Wolfgang ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Excessive nntp reads since today 2012-06-12 13:11 ` Wolfgang Jenkner @ 2012-06-12 13:36 ` Tassilo Horn 2012-06-12 14:35 ` Wolfgang Jenkner 0 siblings, 1 reply; 19+ messages in thread From: Tassilo Horn @ 2012-06-12 13:36 UTC (permalink / raw) To: ding Wolfgang Jenkner <wjenkner@inode.at> writes: >> My `gnus-fetch-old-headers' is 'some, so it might want to fetch some >> older messages to connect new articles in a thread, but not so many. >> I just entered the gmane xetex group which had 4 new articles. The >> summary showed those 4 articles + 2 old articles from yesterday (the >> 4 new were replies of the 2 old ones). But when entering the group, >> the "nntp read: <x> kb" message counted to more than 12.000. >> >> I suspect this change is the culprit, so I added Wolfgang to the Cc. >> >> ,---- >> | commit 44f603535c63aab124e139b145fce20fff488f38 >> | Author: Wolfgang Jenkner <wjenkner@inode.at> >> | Date: Mon Jun 11 23:49:17 2012 +0200 >> | >> | Make `A T' work when agentized >> | >> | * gnus-agent.el (gnus-agent-retrieve-headers): Recalculate the range of >> | articles when fetch-old is non-nil (bug#11370). >> `---- > > I admit that it hadn't occurred to me to test this patch with > non-default values of gnus-fetch-old-headers, but the docstring of this > variable actually seems to match the behaviour you describe... It matches the behavior in that it had to fetch 2 additional messages to fill in gaps in lose thread branches. But the two old messages were from yesterday, and that's a low-traffic group with about 20 messages in the last week. There's no chance that this required fetching 12 MB of header data, right? Bye, Tassilo ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Excessive nntp reads since today 2012-06-12 13:36 ` Tassilo Horn @ 2012-06-12 14:35 ` Wolfgang Jenkner 2012-06-12 15:56 ` Wolfgang Jenkner 2012-06-12 16:31 ` Tassilo Horn 0 siblings, 2 replies; 19+ messages in thread From: Wolfgang Jenkner @ 2012-06-12 14:35 UTC (permalink / raw) To: Tassilo Horn; +Cc: ding On Tue, Jun 12 2012, Tassilo Horn wrote: > Wolfgang Jenkner <wjenkner@inode.at> writes: > >>> My `gnus-fetch-old-headers' is 'some, so it might want to fetch some >>> older messages to connect new articles in a thread, but not so many. >>> I just entered the gmane xetex group which had 4 new articles. The >>> summary showed those 4 articles + 2 old articles from yesterday (the >>> 4 new were replies of the 2 old ones). But when entering the group, >>> the "nntp read: <x> kb" message counted to more than 12.000. >>> >>> I suspect this change is the culprit, so I added Wolfgang to the Cc. >>> >>> ,---- >>> | commit 44f603535c63aab124e139b145fce20fff488f38 >>> | Author: Wolfgang Jenkner <wjenkner@inode.at> >>> | Date: Mon Jun 11 23:49:17 2012 +0200 >>> | >>> | Make `A T' work when agentized >>> | >>> | * gnus-agent.el (gnus-agent-retrieve-headers): Recalculate the range of >>> | articles when fetch-old is non-nil (bug#11370). >>> `---- >> >> I admit that it hadn't occurred to me to test this patch with >> non-default values of gnus-fetch-old-headers, but the docstring of this >> variable actually seems to match the behaviour you describe... > > It matches the behavior in that it had to fetch 2 additional messages to > fill in gaps in lose thread branches. The docstring states that it fetches all old headers (though only some subset of them is displayed). > But the two old messages were from yesterday, and that's a low-traffic > group with about 20 messages in the last week. There's no chance that > this required fetching 12 MB of header data, right? Perhaps tracing (or stepping through) gnus-agent-retrieve-headers could give a clue? Wolfgang ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Excessive nntp reads since today 2012-06-12 14:35 ` Wolfgang Jenkner @ 2012-06-12 15:56 ` Wolfgang Jenkner 2012-06-12 16:31 ` Tassilo Horn 1 sibling, 0 replies; 19+ messages in thread From: Wolfgang Jenkner @ 2012-06-12 15:56 UTC (permalink / raw) To: Tassilo Horn; +Cc: ding > The docstring states that it fetches all old headers (though only some > subset of them is displayed). > On Tue, Jun 12 2012, Tassilo Horn wrote: >> But the two old messages were from yesterday, and that's a low-traffic >> group with about 20 messages in the last week. There's no chance that >> this required fetching 12 MB of header data, right? Actually, that's the right order of magnitude for fetching all old headers. Just for the record: In a clean environment, as a user with no Gnus related files at $HOME, and with an emacs without the patch, subscribe to, and enter gmane.comp.tex.xetex like this env NNTPSERVER=news.gmane.org emacs -Q -nw ESC x g n u s RET S s g m a n e . c o m p . t e x . x e t e x RET g RET RET Gnus retrieves about 8M header data (look at the size of the " *nntpd*" buffer). Wolfgang ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Excessive nntp reads since today 2012-06-12 14:35 ` Wolfgang Jenkner 2012-06-12 15:56 ` Wolfgang Jenkner @ 2012-06-12 16:31 ` Tassilo Horn 2012-06-13 13:48 ` Wolfgang Jenkner 2012-09-05 13:56 ` Lars Ingebrigtsen 1 sibling, 2 replies; 19+ messages in thread From: Tassilo Horn @ 2012-06-12 16:31 UTC (permalink / raw) To: ding Wolfgang Jenkner <wjenkner@inode.at> writes: >> It matches the behavior in that it had to fetch 2 additional messages >> to fill in gaps in lose thread branches. > > The docstring states that it fetches all old headers (though only some > subset of them is displayed). You are right. But speaking from experience it didn't do so, yet the effect of connecting loose threads with old read articles somehow seemed to work. Ok, now I've edebugged the function as you suggested and checked what's going on. The difference between now and then is that now all headers of a group are fetched once and put into the .overview (NOV) files. Then they are cached and entering a group (even with 'some) is fast again. So basically, before uncached-articles was always the list of unread articles, now it is (set-difference all-articles articles-in-overview). (if (setq uncached-articles (gnus-agent-uncached-articles articles group t)) (progn ;; Populate nntp-server-buffer with uncached headers (set-buffer nntp-server-buffer) (erase-buffer) The reason that I get those excessive nntp reads (only once for each group) is that my overview files didn't start with article 1, because when subscribing to a new group, I restricted fetching by entering it with, say, C-u 1000 RET and then catching up. So to conclude: - Your patch is correct with respect to the docs - Your patch is bad, because now you can't use 'some for `gnus-fetch-old-headers' unless you have a super-fast internet connection. (Several gmane groups have millions of messages which on first entering will all be downloaded. No way to restrict that with a prefix arg as I always did. Also, you end up with huge .overview files, which slow down Gnus' operations quite a bit.) - 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. Now what? Possibly `gnus-fetch-old-headers' should be split into two variables to entangle fetching from displaying? That'd be pretty bad with respect to backwards compatibility... Or how about allowing values like '(some . 100) meaning fetch at most 100 old headers and display old articles where needed to fill loose threads? Bye, Tassilo ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Excessive nntp reads since today 2012-06-12 16:31 ` Tassilo Horn @ 2012-06-13 13:48 ` Wolfgang Jenkner 2012-06-13 15:18 ` Tassilo Horn 2012-09-05 13:56 ` Lars Ingebrigtsen 1 sibling, 1 reply; 19+ messages in thread From: Wolfgang Jenkner @ 2012-06-13 13:48 UTC (permalink / raw) To: Tassilo Horn; +Cc: ding On Tue, Jun 12 2012, Tassilo Horn wrote: > - 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. 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 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). Wolfgang ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Excessive nntp reads since today 2012-06-13 13:48 ` Wolfgang Jenkner @ 2012-06-13 15:18 ` Tassilo Horn 2012-06-13 16:36 ` Wolfgang Jenkner 0 siblings, 1 reply; 19+ messages in thread From: Tassilo Horn @ 2012-06-13 15:18 UTC (permalink / raw) To: ding; +Cc: Lars Magne Ingebrigtsen Wolfgang Jenkner <wjenkner@inode.at> 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Excessive nntp reads since today 2012-06-13 15:18 ` Tassilo Horn @ 2012-06-13 16:36 ` Wolfgang Jenkner 2012-06-13 18:57 ` Tassilo Horn 0 siblings, 1 reply; 19+ messages in thread From: Wolfgang Jenkner @ 2012-06-13 16:36 UTC (permalink / raw) To: Tassilo Horn; +Cc: ding, Lars Magne Ingebrigtsen On Wed, Jun 13 2012, Tassilo Horn wrote: > 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. Well, as I said, when plugged the agent cache is, IMHO, designed to be transparent with respect to the server. This implies that the summary should be the same as if the agent were non used at all. Only when the agent is unplugged it effectively is the server and you may expose its internal state in the summary. Of course, these points may be less important than I think them to be :-) Wolfgang ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Excessive nntp reads since today 2012-06-13 16:36 ` Wolfgang Jenkner @ 2012-06-13 18:57 ` Tassilo Horn 2012-06-16 11:37 ` Wolfgang Jenkner 0 siblings, 1 reply; 19+ messages in thread From: Tassilo Horn @ 2012-06-13 18:57 UTC (permalink / raw) To: ding; +Cc: Lars Magne Ingebrigtsen Wolfgang Jenkner <wjenkner@inode.at> writes: Hi Wolfgang, >> 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. > > Well, as I said, when plugged the agent cache is, IMHO, designed to be > transparent with respect to the server. > > This implies that the summary should be the same as if the agent were > non used at all. > > Only when the agent is unplugged it effectively is the server and you > may expose its internal state in the summary. > > Of course, these points may be less important than I think them to > be :-) Yes, I think you have a bit too high expectations here. I mean, the real server is some reasonably well equipped machine, but Gnus possibly runs on some small netbook with few RAM and disk space. Thus there shouldn't be a need to have subscribed groups to be complete (header) mirrors of all available messages on the server. For example, gmane.emacs.help currently has an 26MB .overview here, and gmane.emacs.devel has nearly twice as many messages thus probably it would have a 50MB overview. And that's only for parts of the message headers. And finally, nobody has ever complained about the agent not fetching all old message headers. Bye, Tassilo ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Excessive nntp reads since today 2012-06-13 18:57 ` Tassilo Horn @ 2012-06-16 11:37 ` Wolfgang Jenkner 2012-06-16 12:53 ` Tassilo Horn 0 siblings, 1 reply; 19+ messages in thread From: Wolfgang Jenkner @ 2012-06-16 11:37 UTC (permalink / raw) To: Tassilo Horn; +Cc: ding, Lars Magne Ingebrigtsen On Wed, Jun 13 2012, Tassilo Horn wrote: > Wolfgang Jenkner <wjenkner@inode.at> writes: > >> Well, as I said, when plugged the agent cache is, IMHO, designed to be >> transparent with respect to the server. >> >> This implies that the summary should be the same as if the agent were >> non used at all. >> >> Only when the agent is unplugged it effectively is the server and you >> may expose its internal state in the summary. > Thus there shouldn't be a need to have subscribed groups to be > complete (header) mirrors of all available messages on the server. Of course not. Nobody said that the agent should cache all headers. Quite the contrary, actually :-) Wolfgang ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Excessive nntp reads since today 2012-06-16 11:37 ` Wolfgang Jenkner @ 2012-06-16 12:53 ` Tassilo Horn 2012-06-16 14:18 ` Wolfgang Jenkner 0 siblings, 1 reply; 19+ messages in thread From: Tassilo Horn @ 2012-06-16 12:53 UTC (permalink / raw) To: ding; +Cc: Lars Magne Ingebrigtsen Wolfgang Jenkner <wjenkner@inode.at> writes: >>> Well, as I said, when plugged the agent cache is, IMHO, designed to >>> be transparent with respect to the server. >>> >>> This implies that the summary should be the same as if the agent >>> were non used at all. >>> >>> Only when the agent is unplugged it effectively is the server and >>> you may expose its internal state in the summary. > >> Thus there shouldn't be a need to have subscribed groups to be >> complete (header) mirrors of all available messages on the server. > > Of course not. Nobody said that the agent should cache all headers. > > Quite the contrary, actually :-) But that's actually the effect of your patch. If the fetch-old argument is something not numerical, it'll fetch all headers starting with article number 1 and cache them in the .overview. Bye, Tassilo ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Excessive nntp reads since today 2012-06-16 12:53 ` Tassilo Horn @ 2012-06-16 14:18 ` Wolfgang Jenkner 0 siblings, 0 replies; 19+ messages in thread From: Wolfgang Jenkner @ 2012-06-16 14:18 UTC (permalink / raw) To: Tassilo Horn; +Cc: ding, Lars Magne Ingebrigtsen On Sat, Jun 16 2012, Tassilo Horn wrote: > Wolfgang Jenkner <wjenkner@inode.at> writes: > >>>> Well, as I said, when plugged the agent cache is, IMHO, designed to >>>> be transparent with respect to the server. >>>> >>>> This implies that the summary should be the same as if the agent >>>> were non used at all. >>>> >>>> Only when the agent is unplugged it effectively is the server and >>>> you may expose its internal state in the summary. >> >>> Thus there shouldn't be a need to have subscribed groups to be >>> complete (header) mirrors of all available messages on the server. >> >> Of course not. Nobody said that the agent should cache all headers. >> >> Quite the contrary, actually :-) > > But that's actually the effect of your patch. If the fetch-old argument > is something not numerical, it'll fetch all headers starting with > article number 1 and cache them in the .overview. And that's consistent with the principles I humbly think the agent is based upon and which I stated above. Now, it's quite possible that these principles exist only in my imagination or that the convenience of making an exception and handling the case fetch-old=some specially would outweigh the resulting conceptual inconsistency. Please note, however, that not only the "bad new" behaviour has been documented since at least 2005 but also that Kevin Greiner, who rewrote a lot of the agent stuff, actually significantly clarified the meaning of `some' as value of gnus-fetch-old-headers on 2005-11-20 [*]. Wolfgang [*] Here's the diff: diff --git a/lisp/gnus-sum.el b/lisp/gnus-sum.el index dfc3c09..9df8131 100644 --- a/lisp/gnus-sum.el +++ b/lisp/gnus-sum.el @@ -63,17 +63,21 @@ it will be killed sometime later." (defcustom gnus-fetch-old-headers nil "*Non-nil means that Gnus will try to build threads by grabbing old headers. -If an unread article in the group refers to an older, already read (or -just marked as read) article, the old article will not normally be -displayed in the Summary buffer. If this variable is t, Gnus -will attempt to grab the headers to the old articles, and thereby -build complete threads. If it has the value `some', only enough -headers to connect otherwise loose threads will be displayed. This -variable can also be a number. In that case, no more than that number -of old headers will be fetched. If it has the value `invisible', all +If an unread article in the group refers to an older, already +read (or just marked as read) article, the old article will not +normally be displayed in the Summary buffer. If this variable is +t, Gnus will attempt to grab the headers to the old articles, and +thereby build complete threads. If it has the value `some', all +old headers will be fetched but only enough headers to connect +otherwise loose threads will be displayed. This variable can +also be a number. In that case, no more than that number of old +headers will be fetched. If it has the value `invisible', all old headers will be fetched, but none will be displayed. -The server has to support NOV for any of this to work." +The server has to support NOV for any of this to work. + +This feature can seriously impact performance it ignores all +locally cached header entries." :group 'gnus-thread :type '(choice (const :tag "off" nil) (const :tag "on" t) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Excessive nntp reads since today 2012-06-12 16:31 ` Tassilo Horn 2012-06-13 13:48 ` Wolfgang Jenkner @ 2012-09-05 13:56 ` Lars Ingebrigtsen 2012-09-05 14:38 ` Tassilo Horn 1 sibling, 1 reply; 19+ messages in thread From: Lars Ingebrigtsen @ 2012-09-05 13:56 UTC (permalink / raw) To: Tassilo Horn; +Cc: ding Tassilo Horn <tassilo@member.fsf.org> writes: > - Your patch is correct with respect to the docs > > - Your patch is bad, because now you can't use 'some for > `gnus-fetch-old-headers' unless you have a super-fast internet > connection. `some' was never meant to fetch everything -- that was what t was for. -- (domestic pets only, the antidote for overdose, milk.) http://lars.ingebrigtsen.no * Sent from my Emacs ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Excessive nntp reads since today 2012-09-05 13:56 ` Lars Ingebrigtsen @ 2012-09-05 14:38 ` Tassilo Horn 2012-09-05 16:19 ` Lars Ingebrigtsen 0 siblings, 1 reply; 19+ messages in thread From: Tassilo Horn @ 2012-09-05 14:38 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: ding Lars Ingebrigtsen <larsi@gnus.org> writes: >> - Your patch is correct with respect to the docs >> >> - Your patch is bad, because now you can't use 'some for >> `gnus-fetch-old-headers' unless you have a super-fast internet >> connection. > > `some' was never meant to fetch everything -- that was what t was for. Then the docs were wrong: ,----[ C-h v gnus-fetch-old-headers RET ] | gnus-fetch-old-headers is a variable defined in `gnus-sum.el'. | | Documentation: | [...] If it has the value `some', all old headers will be fetched but | only enough headers to connect otherwise loose threads will be | displayed. [...] `---- Wolfgang fixed the implementation to reflect exactly what the docs say. IMHO, we'd better have fixed the docs and let the implementation as it has been. Bye, Tassilo ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Excessive nntp reads since today 2012-09-05 14:38 ` Tassilo Horn @ 2012-09-05 16:19 ` Lars Ingebrigtsen 2012-09-05 17:16 ` Tassilo Horn 0 siblings, 1 reply; 19+ messages in thread From: Lars Ingebrigtsen @ 2012-09-05 16:19 UTC (permalink / raw) To: Tassilo Horn; +Cc: ding Tassilo Horn <tsdh@gnu.org> writes: > Then the docs were wrong: > > ,----[ C-h v gnus-fetch-old-headers RET ] > | gnus-fetch-old-headers is a variable defined in `gnus-sum.el'. > | > | Documentation: > | [...] If it has the value `some', all old headers will be fetched but > | only enough headers to connect otherwise loose threads will be > | displayed. [...] > `---- > > Wolfgang fixed the implementation to reflect exactly what the docs say. > IMHO, we'd better have fixed the docs and let the implementation as it > has been. Yeah, but that's after the clarification. :-) They used to say: -displayed in the Summary buffer. If this variable is t, Gnus -will attempt to grab the headers to the old articles, and thereby -build complete threads. If it has the value `some', only enough -headers to connect otherwise loose threads will be displayed. This -variable can also be a number. In that case, no more than that number -of old headers will be fetched. If it has the value `invisible', all i.e., it didn't say that all headers would be fetched... -- (domestic pets only, the antidote for overdose, milk.) http://lars.ingebrigtsen.no * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Excessive nntp reads since today 2012-09-05 16:19 ` Lars Ingebrigtsen @ 2012-09-05 17:16 ` Tassilo Horn 2012-09-05 17:34 ` Wolfgang Jenkner 0 siblings, 1 reply; 19+ messages in thread From: Tassilo Horn @ 2012-09-05 17:16 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: ding, Wolfgang Jenkner Lars Ingebrigtsen <larsi@gnus.org> writes: >> Then the docs were wrong: >> >> ,----[ C-h v gnus-fetch-old-headers RET ] >> | gnus-fetch-old-headers is a variable defined in `gnus-sum.el'. >> | >> | Documentation: >> | [...] If it has the value `some', all old headers will be fetched but >> | only enough headers to connect otherwise loose threads will be >> | displayed. [...] >> `---- >> >> Wolfgang fixed the implementation to reflect exactly what the docs say. >> IMHO, we'd better have fixed the docs and let the implementation as it >> has been. > > Yeah, but that's after the clarification. :-) They used to say: > > -displayed in the Summary buffer. If this variable is t, Gnus > -will attempt to grab the headers to the old articles, and thereby > -build complete threads. If it has the value `some', only enough > -headers to connect otherwise loose threads will be displayed. This > -variable can also be a number. In that case, no more than that number > -of old headers will be fetched. If it has the value `invisible', all > > i.e., it didn't say that all headers would be fetched... Oh, Wolfgang, you prankster. ;-) So what now? For what it's worth, I'm for reverting that commit and clarifying the docs that 'some won't be able to fill loose threads in case it references articles for which no headers have been fetched. But that's not much on an issue: over time, you'll have all headers for the active threads, just not for very old ones. Bye, Tassilo ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Excessive nntp reads since today 2012-09-05 17:16 ` Tassilo Horn @ 2012-09-05 17:34 ` Wolfgang Jenkner 2012-09-05 17:36 ` Tassilo Horn 0 siblings, 1 reply; 19+ messages in thread From: Wolfgang Jenkner @ 2012-09-05 17:34 UTC (permalink / raw) To: Tassilo Horn; +Cc: Lars Ingebrigtsen, ding On Wed, Sep 05 2012, Tassilo Horn wrote: > Lars Ingebrigtsen <larsi@gnus.org> writes: > >>> Then the docs were wrong: >>> >>> ,----[ C-h v gnus-fetch-old-headers RET ] >>> | gnus-fetch-old-headers is a variable defined in `gnus-sum.el'. >>> | >>> | Documentation: >>> | [...] If it has the value `some', all old headers will be fetched but >>> | only enough headers to connect otherwise loose threads will be >>> | displayed. [...] >>> `---- >>> >>> Wolfgang fixed the implementation to reflect exactly what the docs say. >>> IMHO, we'd better have fixed the docs and let the implementation as it >>> has been. >> >> Yeah, but that's after the clarification. :-) They used to say: >> >> -displayed in the Summary buffer. If this variable is t, Gnus >> -will attempt to grab the headers to the old articles, and thereby >> -build complete threads. If it has the value `some', only enough >> -headers to connect otherwise loose threads will be displayed. This >> -variable can also be a number. In that case, no more than that number >> -of old headers will be fetched. If it has the value `invisible', all >> >> i.e., it didn't say that all headers would be fetched... > > Oh, Wolfgang, you prankster. ;-) ??? I think you are misunderstanding. As I said, that clarification was made in 2005-11-20 by Kevin Greiner. Wolfgang ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Excessive nntp reads since today 2012-09-05 17:34 ` Wolfgang Jenkner @ 2012-09-05 17:36 ` Tassilo Horn 0 siblings, 0 replies; 19+ messages in thread From: Tassilo Horn @ 2012-09-05 17:36 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: ding Wolfgang Jenkner <wjenkner@inode.at> writes: >>>> Then the docs were wrong: >>>> >>>> ,----[ C-h v gnus-fetch-old-headers RET ] >>>> | gnus-fetch-old-headers is a variable defined in `gnus-sum.el'. >>>> | >>>> | Documentation: >>>> | [...] If it has the value `some', all old headers will be fetched but >>>> | only enough headers to connect otherwise loose threads will be >>>> | displayed. [...] >>>> `---- >>>> >>>> Wolfgang fixed the implementation to reflect exactly what the docs >>>> say. IMHO, we'd better have fixed the docs and let the >>>> implementation as it has been. >>> >>> Yeah, but that's after the clarification. :-) They used to say: >>> >>> -displayed in the Summary buffer. If this variable is t, Gnus >>> -will attempt to grab the headers to the old articles, and thereby >>> -build complete threads. If it has the value `some', only enough >>> -headers to connect otherwise loose threads will be displayed. This >>> -variable can also be a number. In that case, no more than that number >>> -of old headers will be fetched. If it has the value `invisible', all >>> >>> i.e., it didn't say that all headers would be fetched... >> >> Oh, Wolfgang, you prankster. ;-) > > ??? I think you are misunderstanding. Indeed. > As I said, that clarification was made in 2005-11-20 by Kevin Greiner. Ok, ok. My suggestion stands as-is anyway. Bye, Tassilo ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2012-09-05 17:36 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-06-12 12:11 Excessive nntp reads since today Tassilo Horn 2012-06-12 13:11 ` Wolfgang Jenkner 2012-06-12 13:36 ` Tassilo Horn 2012-06-12 14:35 ` Wolfgang Jenkner 2012-06-12 15:56 ` Wolfgang Jenkner 2012-06-12 16:31 ` Tassilo Horn 2012-06-13 13:48 ` Wolfgang Jenkner 2012-06-13 15:18 ` Tassilo Horn 2012-06-13 16:36 ` Wolfgang Jenkner 2012-06-13 18:57 ` Tassilo Horn 2012-06-16 11:37 ` Wolfgang Jenkner 2012-06-16 12:53 ` Tassilo Horn 2012-06-16 14:18 ` Wolfgang Jenkner 2012-09-05 13:56 ` Lars Ingebrigtsen 2012-09-05 14:38 ` Tassilo Horn 2012-09-05 16:19 ` Lars Ingebrigtsen 2012-09-05 17:16 ` Tassilo Horn 2012-09-05 17:34 ` Wolfgang Jenkner 2012-09-05 17:36 ` Tassilo Horn
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).