From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/49320 Path: main.gmane.org!not-for-mail From: Kevin Greiner Newsgroups: gmane.emacs.gnus.general Subject: Re: gnus-agent-fetch-selected-article Date: Thu, 16 Jan 2003 22:07:04 -0600 Sender: owner-ding@hpc.uh.edu Message-ID: References: <20021211092015.18546.h016.c001.wm@mail.xpediantsolutions.com.criticalpath.net> <84fzscx09b.fsf@lucy.cs.uni-dortmund.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: main.gmane.org 1042776423 25169 80.91.224.249 (17 Jan 2003 04:07:03 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 17 Jan 2003 04:07:03 +0000 (UTC) Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18ZNmW-0006XX-00 for ; Fri, 17 Jan 2003 05:07:00 +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 18ZNnB-00038p-00; Thu, 16 Jan 2003 22:07:41 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Thu, 16 Jan 2003 22:08:38 -0600 (CST) Original-Received: from sclp3.sclp.com (sclp3.sclp.com [66.230.238.2]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id WAA14937 for ; Thu, 16 Jan 2003 22:08:20 -0600 (CST) Original-Received: (qmail 91669 invoked by alias); 17 Jan 2003 04:07:19 -0000 Original-Received: (qmail 91664 invoked from network); 17 Jan 2003 04:07:18 -0000 Original-Received: from quimby.gnus.org (80.91.224.244) by 66.230.238.6 with SMTP; 17 Jan 2003 04:07:18 -0000 Original-Received: from news by quimby.gnus.org with local (Exim 3.12 #1 (Debian)) id 18ZNui-0000G6-00 for ; Fri, 17 Jan 2003 05:15:28 +0100 Original-To: ding@gnus.org Original-Path: not-for-mail Original-Newsgroups: gnus.ding Original-Lines: 216 Original-NNTP-Posting-Host: 216.12.206.10 Original-X-Trace: quimby.gnus.org 1042776928 997 216.12.206.10 (17 Jan 2003 04:15:28 GMT) Original-X-Complaints-To: usenet@quimby.gnus.org Original-NNTP-Posting-Date: 17 Jan 2003 04:15:28 GMT User-Agent: Gnus/5.090013 (Oort Gnus v0.13) Emacs/21.2 (i386-msvc-nt5.1.2600) Cancel-Lock: sha1:wYREGlxKAG8Sl6XOeOarUh9COH4= Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:49320 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:49320 --=-=-= David S Goldberg writes: >>>>>> On Thu, 09 Jan 2003 16:48:18 -0600, kgreiner@xpediantsolutions.com said: >>> OK, I repeated the problem by running expiry. > >> Is this group expiration or agent expiration? > > I do C-c M-C-x in the *Group* buffer, which I assume is group > expiration (somehow I thought I recalled agent expiration being rolled > into that, but I guess not). In general agent expiration is only done when directed. However, gnus-request-expire-articles was modified to expire articles in the agent as they are expired in the group. So, it looks like your memory was correct. > >> [...] >> In your case, regeneration did the following. > >> 1) You had 1759 entries looking like (n). All but ten of these >> entries were deleted. >> 2) An entry was added for article 12414. The article body has been >> fetched. >> 3) An entry for article 414 was deleted. The only significance is >> that the agent thought that this article's body had been fetched. > > That's bizarre. I have some big gaps in there, but that number hasn't > been seen for ages. > >> The first item implies that the nnimap backend tried to fetch nearly >> 1800 headers but failed on nearly every one. That would result in (n) >> entries in the .agentview that are not matched to NOV entries in the >> .overview. While inefficient, no harm should have resulted. > > I keep meaning to B-m everything back into the same group to compress > the range but never seem to think of it when I'm actually working in > gnus :-) > >> Could the second and third be the result of moving an article? Is > > 12414 is actually a pretty old article that is kept around with a tick > (I have several tens of those). It was created long before the > current gnus-agent code. I happened to need to refer to it, hence it > was downloaded. > >> there any significance to the 414 appearing within 12414? > > Maybe, since article 414 went away a long time ago. Certainly long > before 12414 was even created. Actually, I was thinking that the backend may have generated 414 from 12414 as part of moving an article. Now, I don't think that that happens at all. > >> Could the nnimap backend be re-using article numbers? If so, that >> would explain everything. > > I doubt it. I checked with my mail admin (it's good to be his boss, > response to questions is usually very good :-) and as far as he could > tell, cyrus uses monotonically increasing numbers though there's > probably a point at which it would loop back to something small. I > didn't ask him to check the cyrus source to see where, though. > >> If you don't mind, I'm really appreciate more assistence. > >> Please make the following configuration changes. >> 1) Set gnus-verbose to 10. > > Been done for a while :-) > >> 2) Set message-log-max to 10000 > > This is log-message-max-size in XEmacs and it's default is 50000. > >> 3) If it doesn't already, edit your gnus-summary-line-format to >> include the %N format. This will result in the article number >> appearing in the summary. > > Already there. I need them for a utility function I wrote for easily > attaching messages. > >> Then test as follows >> 1) Execute (gnus) >> 2) load the attached file. >> 3) Open the group that is giving you trouble. If it doesn't display >> correctly, close it and run regenerate. >> 4) Open the group again. If you check *messages*, you should see that >> fetch-headers had no undownloaded headers to fetch. >> 5) Close the group. >> 6) Do something to break the group. >> 7) Open the group again and execute '/ N' to load new messages. Did >> they appear? Repeat until you get the bug to appear. >> 8) Close the group, turn off the agent, then reopen the group. > >> I'd like a copy of the *message* buffer. I'd also like you to >> identify the article # of the new article(s) that had not appeared due >> to the agent. You can sanitize the message log of all names if it >> matters to you. All I need are the article numbers. > > OK, I did all that. I'm sending you the message log under separate > cover. It's not huge, but big enough that I'm not sure the rest of > the list wants to be burdened with it. Sorry, but the dianostics didn't execute. I'm assuming that gnus didn't load gnus-agent until after you had loaded the temp file. As a result, the unmodified agent overwrote my diagnostics. Please repeat the test except that, before loading the temp file, you do a M-x load-library gnus-agent. I'm including a patch that I developed in response to another thread. It fixes a display update problem that I found in summary (At least I hope that it does :) ). There is a small chance that your problem has to do with updating the summary buffer rather than the agent. --=-=-= Content-Disposition: attachment; filename=gnus-sum-patch.txt Content-Description: Patch to gnus-sum --- ../lisp.cvs_ref/gnus-sum.el Mon Jan 13 23:06:13 2003 +++ gnus-sum.el Thu Jan 16 16:11:41 2003 @@ -4022,40 +4022,41 @@ (gnus-summary-goto-subject article) (let* ((datal (gnus-data-find-list article)) (data (car datal)) - (length (when (cdr datal) - (- (gnus-data-pos data) - (gnus-data-pos (cadr datal))))) (buffer-read-only nil) (level (gnus-summary-thread-level))) (gnus-delete-line) - (gnus-summary-insert-line - header level nil - (memq article gnus-newsgroup-undownloaded) - (gnus-article-mark article) - (memq article gnus-newsgroup-replied) - (memq article gnus-newsgroup-expirable) - ;; Only insert the Subject string when it's different - ;; from the previous Subject string. - (if (and - gnus-show-threads - (gnus-subject-equal - (condition-case () - (mail-header-subject - (gnus-data-header - (cadr - (gnus-data-find-list - article - (gnus-data-list t))))) - ;; Error on the side of excessive subjects. - (error "")) - (mail-header-subject header))) - "" - (mail-header-subject header)) - nil (cdr (assq article gnus-newsgroup-scored)) - (memq article gnus-newsgroup-processable)) - (when length - (gnus-data-update-list - (cdr datal) (- length (- (gnus-data-pos data) (point)))))))) + (let ((inserted (- (point) + (progn + (gnus-summary-insert-line + header level nil + (memq article gnus-newsgroup-undownloaded) + (gnus-article-mark article) + (memq article gnus-newsgroup-replied) + (memq article gnus-newsgroup-expirable) + ;; Only insert the Subject string when it's different + ;; from the previous Subject string. + (if (and + gnus-show-threads + (gnus-subject-equal + (condition-case () + (mail-header-subject + (gnus-data-header + (cadr + (gnus-data-find-list + article + (gnus-data-list t))))) + ;; Error on the side of excessive subjects. + (error "")) + (mail-header-subject header))) + "" + (mail-header-subject header)) + nil (cdr (assq article gnus-newsgroup-scored)) + (memq article gnus-newsgroup-processable)) + (point))))) + (when (cdr datal) + (gnus-data-update-list + (cdr datal) + (- (gnus-data-pos data) (gnus-data-pos (cadr datal)) inserted))))))) (defun gnus-summary-update-article (article &optional iheader) "Update ARTICLE in the summary buffer." @@ -6776,7 +6777,7 @@ (gnus-summary-goto-subject article t))) (gnus-summary-limit (append articles gnus-newsgroup-limit)) (gnus-summary-position-point)) - + (defun gnus-summary-goto-subject (article &optional force silent) "Go the subject line of ARTICLE. If FORCE, also allow jumping to articles not currently shown." --=-=-= Kevin --=-=-=--