From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/43647 Path: quimby.gnus.org!not-for-mail From: Harry Putnam Newsgroups: gmane.emacs.gnus.general Subject: Re: What is happening in agentized groups? Date: Mon, 25 Feb 2002 20:31:59 -0800 Message-ID: References: <2nsn7pnzy6.fsf@zsh.cs.rochester.edu> <2n8z9h58sp.fsf@zsh.cs.rochester.edu> NNTP-Posting-Host: quimby2.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: quimby2.netfonds.no 1014698601 16929 195.204.10.66 (26 Feb 2002 04:43:21 GMT) X-Complaints-To: usenet@quimby2.netfonds.no NNTP-Posting-Date: 26 Feb 2002 04:43:21 GMT Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by quimby2.netfonds.no with esmtp (Exim 3.12 #1 (Debian)) id 16fZSS-0004Os-00; Tue, 26 Feb 2002 05:43:20 +0100 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 16fZM0-00079T-00; Mon, 25 Feb 2002 22:36:40 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Mon, 25 Feb 2002 22:36:40 -0600 (CST) Original-Received: from sclp3.sclp.com (qmailr@sclp3.sclp.com [209.196.61.66]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id WAA17701 for ; Mon, 25 Feb 2002 22:36:27 -0600 (CST) Original-Received: (qmail 11843 invoked by alias); 26 Feb 2002 04:36:09 -0000 Original-Received: (qmail 11838 invoked from network); 26 Feb 2002 04:36:05 -0000 Original-Received: from smtp.newsguy.com (HELO newsguy.com) (209.155.56.71) by gnus.org with SMTP; 26 Feb 2002 04:36:05 -0000 Original-Received: from reader.local.lan (adsl-66.51.210.228.dslextreme.com [66.51.210.228]) by newsguy.com (8.9.1a/8.9.1) with ESMTP id UAA01659 for ; Mon, 25 Feb 2002 20:35:34 -0800 (PST) Original-Received: (from reader@localhost) by reader.local.lan (8.11.6/8.11.6) id g1Q4ZYu04298; Mon, 25 Feb 2002 20:35:34 -0800 X-Authentication-Warning: reader.local.lan: reader set sender to reader@newsguy.com using -f Original-To: ding@gnus.org In-Reply-To: <2n8z9h58sp.fsf@zsh.cs.rochester.edu> (ShengHuo ZHU's message of "Mon, 25 Feb 2002 20:30:30 -0500") User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.1.80 (i586-pc-linux-gnu) Original-Lines: 115 Precedence: list X-Majordomo: 1.94.jlt7 Xref: quimby.gnus.org gmane.emacs.gnus.general:43647 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:43647 ShengHuo ZHU writes: > Harry Putnam writes: > > [...] > >> But back to this business of the undownloaded entries in summary >> buffer: I'm not sure I see what the value of that is. In my case it >> just gives me a huge summary buffer to process if I should happen to >> enter the group with C-u. > > Actually, the word "Undownload" in the summary buffer has different > meaning from the one marked as @. Gnus agent grabs articles in three > steps, 1) updating the active file (automatically when you type 'g' in > the group buffer), 2) braiding .overview files (when you type `J s' or > automatically when you enter the group plugged and if gnus-agent-cache > is non-nil), 3) grabbing the articles (when you type 'J s' and if the > predicates return true). This is getting confusing... These are marked Undownloaded and have the `@' on them. For example, my current gnu.emacs.gnus, if openned with C-u while unplugged begins with: 1@ 31-Dec [ 0: Gnus Agent ] [Undownloaded article 48094] [...] snipped 1200+ just like it with consequtive numbers up to: 1@ 31-Dec [ 0: Gnus Agent ] [Undownloaded article 49318] Then I have the messages beginning: 20O 30-Jan [ 25: A. L. Meyers ] back to the ... 49319 up to: 1R 25-Feb [ 40: Shankar Rao ... 50077 None of the first group are on the server. The lowest number on the server is 48323 I don't really follow the formula you listed, and haven't for probably 2 yrs or more. I do the fetching in batch mode with cron. Which kind of follows the formula I guess. It has worked fine until recently. Possibly since the patch you mention, not sure. > If you enter a group unplugged without step 2, some articles are shown > as "Undownloaded article ???" in the summary buffer, because the NOV What situation would allow a user to enter without step 2? Apparently I am missing step 2 in gnus view of things. But this was not happening until those `Undownloaded' entries started showing up. Maybe this new mechanism doesn't work well with my system of batch downloading, and running unplugged all the time. Allowing a function snarfed from Lars long ago to to handle passing the info from the batch downloads to .newsrc.eld In the unplugged gnus, I call this: (defun pgnus-unplugged () (interactive) (setq gnus-plugged nil) (gnus)) (setq gnus-read-active-file t) To update my groups and mail with the latest stuff gathered in the batch fetchs run by cron. The batch emacs that does that part, loads this function first: (defun lars-fetch-news () (interactive) ;(push "/usr/local/pgnus-0.96/lisp" load-path) (let ((init-file-user "") (gnus-always-read-dribble-file t)) (gnus)) (gnus-group-send-queue) (gnus-agent-fetch-session) (gnus-group-quit)) Sending and fetching In the case above, and in my other groups. If I were to change the @ to % none of them will be downloaded because they do not exist on the server. Yet thousands of them clutter up my summary buffer, if entered with C-u. [...] > Now, the question is what about canceled or expired articles. Ideally, > canceled articles should not be listed, and expired articles on the > server should not either, but agent-expired articles, which are still > on the server, should. However, nnagent knows neither whether they > exist on the server, nor whether they are canceled or expired on the > server (at least not in the current mechanism). So, for the safety > reason, let's assume those articles exist. Isn't there a way for gnus to know if they are not on the server? In the situation I described above, those messages will NEVER be braided into .overview, yet I have thousands of lines of summary buffer devoted to telling me about messages that nothing can be done about. I remember a problem we had going way back before pgnus-0.91 I think. Kind of the reverse situation, where messages in agentized groups would disappear from gnus view when they were expunged off the server, but really still be in the local directory. Lars fixed that in version 91 I believe (or close) and since then gnus knows about the agent articles even if not on the server. Maybe something in that mechanism will help? Or even if it is necessary to poll the server, and find out which are not available, seems it would be better than just continuing to show the Undownloaded summary lines until hell freezes over.