Re: gnus-agent-fetch-selected-article

Re: gnus-agent-fetch-selected-article

[David S Goldberg]

>>>>> On Wed, 11 Dec 2002 09:20:13 -0800 (PST),
>>>>> kgreiner@xpediantsolutions.com said:

> Go into the server mode and check that your server is still
> agentized.  If it isn't, add it again then try to open your group.
> I'm at a client site right now so I can't post anything.  If this
> works for you, please post a followup.  I had this problem myself
> last night but thought that it was due to my on-going development.
> The good news, if you're having the same trouble, is that the
> problem appears to be a one-time event.

Well that was it.  I saw that neither of my nnimap servers, nor my
nntp server were any longer in agent.  So I ran J a on them and once
again gnus-agent-fetch-selected-article is working.  Unfortunately
another problem that I'd reported previously returned.  For some of my
nnimap groups, I am unable to get at new messages.  The group summary
shows some number of new messages and another imap client confirms
they are there.  But nothing I do with Gnus allows me to get them.
Other groups work fine.  Presumably it's still related to the breakage
I had with the generation of the .overview and .agentview files
earlier.  If my kids give me the time (:-) I'll try to step through
code/generate backtraces this weekend.  For now I've just re-removed
the servers from the agent.

A related issue: putting the servers back in the agent and entering a
group resulted in a big flashy rainbow of colors I'd never seen in
gnus before (:-) It's pretty, but IMO distracting.  Is there any way
to use the agent but turn off the visual cues (faces).  I would prefer
to just use the %O spec to give me that in a quieter fashion.

Thanks,
-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: gnus-agent-fetch-selected-article

[David S Goldberg]

>>>>> On Fri, 13 Dec 2002 12:31:30 -0500, David S Goldberg
>>>>> <david.goldberg6@verizon.net> said:

> Well that was it.  I saw that neither of my nnimap servers, nor my
> nntp server were any longer in agent.  So I ran J a on them and once
> again gnus-agent-fetch-selected-article is working.  Unfortunately
> another problem that I'd reported previously returned.  For some of my
> nnimap groups, I am unable to get at new messages.  The group summary
> shows some number of new messages and another imap client confirms
> they are there.  But nothing I do with Gnus allows me to get them.

I was too hasty.  I loaded gnus-agent.el, set debug-on-error and found
that the group it was barfing on was not the group I was having
trouble with.  I emptied the directory it was complaining about and
tried again.  Same thing, different group.  About four times later it
completed successfully, never having complained about the group in
which I was having problems reading new messages.  Entered that group
and the new stuff was there.  So presumably the files in that group
were messed up, but gnus-agent-regenerate was just not ever getting to
it.  Once it did, the group was fine.

Thanks,
-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: gnus-agent-fetch-selected-article

[David S Goldberg]

So I was too hasty again.  I still occasionally see the issue of new
messages not being available.  However, running
(gnus-agent-regenerate-group) on the group in question (there's been
two of them in the last few minutes since I last posted) seems to
solve the problem.  I'd be happy to try to edebug this if someone
would point me at what functions I should be looking at.

Thanks,
-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: gnus-agent-fetch-selected-article

[kgreiner]

David S Goldberg <david.goldberg6@verizon.net> writes:

> So I was too hasty again.  I still occasionally see the issue of new
> messages not being available.  However, running
> (gnus-agent-regenerate-group) on the group in question (there's been
> two of them in the last few minutes since I last posted) seems to
> solve the problem.  I'd be happy to try to edebug this if someone
> would point me at what functions I should be looking at.
>
> Thanks,
> -- 
> Dave Goldberg
> david.goldberg6@verizon.net

Dave,
If you have the 6.113 revision of gnus-agent.el and gnus-verbose
is set to 5, or higher, the *messages* buffer will tell you what
actions were performed to repair your group.  That information may
help identify where you should start debugging.

Sorry about the inconvenience,
Kevin

Re: gnus-agent-fetch-selected-article

[David S Goldberg]

(let's try this again, now that it looks like the list is working
again :-)
>>>>> On Fri, 13 Dec 2002 23:34:47 -0600, kgreiner@xpediantsolutions.com said:

> David S Goldberg <david.goldberg6@verizon.net> writes:

>> So I was too hasty again.  I still occasionally see the issue of new
>> messages not being available.  However, running
>> (gnus-agent-regenerate-group) on the group in question (there's been
>> two of them in the last few minutes since I last posted) seems to
>> solve the problem.  I'd be happy to try to edebug this if someone
>> would point me at what functions I should be looking at.

> If you have the 6.113 revision of gnus-agent.el and gnus-verbose
> is set to 5, or higher, the *messages* buffer will tell you what
> actions were performed to repair your group.  That information may
> help identify where you should start debugging.

Unfortunately setting gnus-verbose to 10 didn't help.
gnus-agent-regenerate-group didn't display anything about repairs.  I
edebugged that function and it looks like it regenerates the overview
file as a matter of course rather than as a result of any error
condition.  The error conditions that would have generated statements
from gnus-verbose don't trigger.  That leads me to believe that the
overview file is getting messed up.  Having lived with it for three
weeks now, I've observed certain features of the problem:

1: it only manifests itself in two groups (both nnimap), my inbox and
the group that holds ding-list messages (ironic, isn't it? :-)

2: it only seems to manifest after one of two operations:

   Running expiry (I use total-expire with varying expiry-waits in
   about 10 groups; I only run expiry by hand a couple times a week),
   which I would expect to affect many more groups, or 

   Moving an article or some number of articles out of the group,
   something that only ever happens from my inbox which suggests the
   ding group shouldn't be affected.

So there's apparently something unique about those groups that's
biting me, but for the life of me, I can't quite figure it out.

Thanks,
-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: gnus-agent-fetch-selected-article

[Kai Großjohann]

David S Goldberg <david.goldberg6@verizon.net> writes:

> So there's apparently something unique about those groups that's
> biting me, but for the life of me, I can't quite figure it out.

Number of dormant or ticked messages?  I think I'm seeing the problem
in groups with no dormant or ticked messages.

Oh, err.  I think I might be seeing a different problem: all unread
articles disappear when I enter a group.  Hitting C-x u in the group
buffer, then J u on the group, fixes the problem.

Hm.
-- 
Ambibibentists unite!

Re: gnus-agent-fetch-selected-article

[David S Goldberg]

>>>>> On Wed, 01 Jan 2003 18:12:16 +0100, kai.grossjohann@uni-duisburg.de (Kai Großjohann) said:

> David S Goldberg <david.goldberg6@verizon.net> writes:
>> So there's apparently something unique about those groups that's
>> biting me, but for the life of me, I can't quite figure it out.

> Number of dormant or ticked messages?  I think I'm seeing the problem
> in groups with no dormant or ticked messages.

Actually both have at least a few ticked messages.  Neither has any
dormant, but then neither do most of my other groups.

> Oh, err.  I think I might be seeing a different problem: all unread
> articles disappear when I enter a group.  Hitting C-x u in the group
> buffer, then J u on the group, fixes the problem.

This sounds similar to what I'm seeing (new messages don't show up,
only the ticks) but I haven't had any luck with J u, only
gnus-agent-regenerate(-group) seems to fix it for me.  I also avoid
need C-x u in the group buffer by exiting the group with Q.

-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: gnus-agent-fetch-selected-article

[kgreiner]

David S Goldberg <david.goldberg6@verizon.net> writes:

>>>>>> On Wed, 01 Jan 2003 18:12:16 +0100, kai.grossjohann@uni-duisburg.de (Kai Großjohann) said:
>
>> David S Goldberg <david.goldberg6@verizon.net> writes:
>>> So there's apparently something unique about those groups that's
>>> biting me, but for the life of me, I can't quite figure it out.
>
>> Number of dormant or ticked messages?  I think I'm seeing the problem
>> in groups with no dormant or ticked messages.
>
> Actually both have at least a few ticked messages.  Neither has any
> dormant, but then neither do most of my other groups.
>
>> Oh, err.  I think I might be seeing a different problem: all unread
>> articles disappear when I enter a group.  Hitting C-x u in the group
>> buffer, then J u on the group, fixes the problem.
>
> This sounds similar to what I'm seeing (new messages don't show up,
> only the ticks) but I haven't had any luck with J u, only
> gnus-agent-regenerate(-group) seems to fix it for me.  I also avoid
> need C-x u in the group buffer by exiting the group with Q.

To be absolutely honest, I can't think of any way for the agent to
mess up this selectively.

David, please make a backup of your group's .overview and .agentview
files before executing gnus-agent-regenerate-group.  You should then
be able to compare the old/new versions to see what regenerate
changed.  If you can tell me what regenerate is fixing, it may help me
understand what is breaking.

Kevin

Re: gnus-agent-fetch-selected-article

[David S Goldberg]

[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]

>>>>> On Tue, 07 Jan 2003 23:22:13 -0600, kgreiner@xpediantsolutions.com said:
> David, please make a backup of your group's .overview and .agentview
> files before executing gnus-agent-regenerate-group.  You should then
> be able to compare the old/new versions to see what regenerate
> changed.  If you can tell me what regenerate is fixing, it may help me
> understand what is breaking.

OK, I repeated the problem by running expiry.  

Verified that the two new messages in my inbox were not available.

Exited the group with Q.

Backed up .overview and .agentview to .{over,agent}view.before.  

Ran gnus-agent-regenerate. The overview file didn't change.  The
.agentview file was cut in half.  I copied it to .agentview.after for
posterity.

Re-entered the group to verify that I could now see the new articles.
I could.

Started writing this message to which I'm attaching the
.agentview.before and .agentview.after (they are quite small).

Thanks,
-- 
Dave Goldberg
david.goldberg6@verizon.net

[-- Attachment #2: .agentview.before --]
[-- Type: text/plain, Size: 1007 bytes --]

((731223 13184 (13188 . 13210)) (731222 (13167 . 13168) (13170 . 13175) (13181 . 13183)) (731221 13146 (13148 . 13153) (13164 . 13166)) (731217 13115 13129 13133) (731214 13072 13074 13077) (731204 13012) (731203 12986 (12995 . 12997) 12999 13002) (731210 12983 13004) (731200 12924) (731180 12650) (731175 12601) (731172 12549) (nil (12159 . 12170) 12173 (12175 . 12181) (12183 . 12184) 12186 12189 (12191 . 12339) (12341 . 12350) (12352 . 12355) (12357 . 12368) (12370 . 12403) (12405 . 12413) (12415 . 12420) (12422 . 12548) (12550 . 12600) (12602 . 12649) (12651 . 12923) (12925 . 12982) (12984 . 12985) (12987 . 12994) 12998 (13000 . 13001) 13003 (13005 . 13011) (13013 . 13071) 13073 (13075 . 13076) (13078 . 13085) (13099 . 13100) 13104 13107 (13110 . 13111) 13127 (13134 . 13135) (13137 . 13139) 13145 13147 (13154 . 13163) 13169 (13176 . 13180) (13185 . 13187) (13211 . 14040)) (731165 12158 (12171 . 12172) 12174 12182 12185 (12187 . 12188) 12190 12340 12351 12356 12369 12404 12!
 
414 12421))
2

[-- Attachment #3: .agentview.after --]
[-- Type: text/plain, Size: 515 bytes --]

((731223 13184 (13188 . 13210)) (731222 (13167 . 13168) (13170 . 13175) (13181 . 13183)) (731221 13146 (13148 . 13153) (13164 . 13166)) (731217 13115 13129 13133) (731214 13072 13074 13077) (nil 13069 13127 13145 13147 13154 13169 13180 (13186 . 13187) 14040) (731204 13012) (731203 12986 (12995 . 12997) 12999 13002) (731210 12983 13004) (731200 12924) (731180 12650) (731175 12601) (731172 12549) (731165 12158 (12171 . 12172) 12174 12182 12185 (12187 . 12188) 12190 12340 12351 12356 12369 12404 12414 12421))
2

Re: gnus-agent-fetch-selected-article

[kgreiner]

[-- Attachment #1: Type: text/plain, Size: 3764 bytes --]

David S Goldberg <david.goldberg6@verizon.net> writes:

>>>>>> On Tue, 07 Jan 2003 23:22:13 -0600, kgreiner@xpediantsolutions.com said:
>> David, please make a backup of your group's .overview and .agentview
>> files before executing gnus-agent-regenerate-group.  You should then
>> be able to compare the old/new versions to see what regenerate
>> changed.  If you can tell me what regenerate is fixing, it may help me
>> understand what is breaking.
>
> OK, I repeated the problem by running expiry.  

Is this group expiration or agent expiration?

>
> Verified that the two new messages in my inbox were not available.
>
> Exited the group with Q.
>
> Backed up .overview and .agentview to .{over,agent}view.before.  
>
> Ran gnus-agent-regenerate. The overview file didn't change.  The
> .agentview file was cut in half.  I copied it to .agentview.after for
> posterity.
>
> Re-entered the group to verify that I could now see the new articles.
> I could.
>
> Started writing this message to which I'm attaching the
> .agentview.before and .agentview.after (they are quite small).
>

Dave,

Thanks for the files.  I uncompressed the alist in each file then
diff'ed the results.

First a little background (it helps me keep all of this straight), the
alist consists of entries in the form (n . m) where n is an article
number as m is the day on which the article's body was fetched.  If an
article header was fetched, but never its body, the entry will look
like (n).

Regeneration first repairs the overview file by
1) Sorting it by ascending article #
2) Removing duplicate articles
3) Inserting missing entries by extracting the headers from the fetched
   article's body.

It then rebuilds the group's article alist to match the overview and
fetched article files.

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.

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.

Could the second and third be the result of moving an article?  Is
there any significance to the 414 appearing within 12414?

Could the nnimap backend be re-using article numbers?  If so, that
would explain everything.

If you don't mind, I'm really appreciate more assistence.

Please make the following configuration changes.
1) Set gnus-verbose to 10.
2) Set message-log-max to 10000
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.

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.

Thanks,
Kevin

[-- Attachment #2: Debug code --]
[-- Type: application/emacs-lisp, Size: 4973 bytes --]

Re: gnus-agent-fetch-selected-article

[David S Goldberg]

>>>>> 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 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.

> 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.

Thanks,
-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: gnus-agent-fetch-selected-article

[Kevin Greiner]

[-- Attachment #1: Type: text/plain, Size: 4785 bytes --]

David S Goldberg <david.goldberg6@verizon.net> 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.


[-- Attachment #2: Patch to gnus-sum --]
[-- Type: text/plain, Size: 3597 bytes --]

--- ../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."

[-- Attachment #3: Type: text/plain, Size: 8 bytes --]


Kevin

Re: gnus-agent-fetch-selected-article

[David S Goldberg]

I've been away the last couple days.  When I tried to apply the patch
after a cvs update this morning it indicated that the patch had
already been applied.  Is that correct?  If so, it hasn't solved the
problem.

Thanks,
-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: gnus-agent-fetch-selected-article

[David S Goldberg]

I was going through old messages on this list and it appears that my
attempt at closure didn't get through (or, more likely, I started to
draft it and it didn't get sent, which is unfortunately not too
uncommon with me).

Previously I could reliably reproduce the following problem, but only
in two nnimap groups: If I either ran expiry or moved an article out
of one of those groups, and a subsequent call to
gnus-group-get-new-news showed new messages in the group, I couldn't
get to the new messages until running gnus-agent-regenerate(-group).
Kevin sent me some code to generate diagnostics but I was never able
to get those diagnostics to run properly.  Perhaps there's some XEmacs
vs Emacs thing there, or perhaps, as I ultimately decided, there's
nothing wrong with the code but rather a problem in the directory.  So
having decided that there must be something "wrong" with my agent
directory hierarchy, I quit XEmacs and removed the hierarchy knowing I
could easily refetch any messages I wanted.  I restarted XEmacs, ran
gnus and have not seen the problem since.  I do see the problem being
discussed in another thread about the %O mark not having the right
value all the time (and I've moved it to the beginning of the line so
variable width fields aren't the cause any more and changing the value
of gnus-agent-mark-unread-after-downloaded), but that can be left to
that other thread.

Thanks,
-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: gnus-agent-fetch-selected-article

[kgreiner]

David S Goldberg <david.goldberg6@verizon.net> writes:

>>>>>> On Wed, 11 Dec 2002 09:20:13 -0800 (PST),
>>>>>> kgreiner@xpediantsolutions.com said:
>
> A related issue: putting the servers back in the agent and entering a
> group resulted in a big flashy rainbow of colors I'd never seen in
> gnus before (:-) It's pretty, but IMO distracting.  Is there any way
> to use the agent but turn off the visual cues (faces).  I would prefer
> to just use the %O spec to give me that in a quieter fashion.
>
> Thanks,
> -- 
> Dave Goldberg
> david.goldberg6@verizon.net

Absolutely. All you need do is customize gnus-summary-highlight.  Just
delete the three cons cells whose sample face has the wheat background
color.

Kevin

Re: gnus-agent-fetch-selected-article

[David S Goldberg]

>>>>> On Fri, 13 Dec 2002 13:30:14 -0600, kgreiner@xpediantsolutions.com said:

> Absolutely. All you need do is customize gnus-summary-highlight.  Just
> delete the three cons cells whose sample face has the wheat background
> color.

Excellent.  Thanks!
-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: gnus-agent-fetch-selected-article

[Kai Großjohann]

David S Goldberg <david.goldberg6@verizon.net> writes:

> Unfortunately
> another problem that I'd reported previously returned.  For some of my
> nnimap groups, I am unable to get at new messages.  The group summary
> shows some number of new messages and another imap client confirms
> they are there.  But nothing I do with Gnus allows me to get them.

This has happened to me, and I did `J u' on the group in the group
buffer, and then it worked.  Does that do the trick for you, too?

I shall try the gnus-agent-regenerate-group trick, as well.
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

gnus-agent-fetch-selected-article

[David S Goldberg]

A while back Kai (I'm pretty sure) implemented the subject function
which can be added to gnus-select-article-hook so that all messages
are downloaded into the agent as they are read.  I really like this
functionality.  However, after doing a CVS update this morning, it's
not working.  I edebugged it and it looks like for some reason
(gnus-agent-method-p gnus-command-method) is returning nil.  Digging
further I see that gnus-agent-method-p checks the variable
gnus-agent-covered-methods which is nil.  In the admittedly short time
I've looked at it, I can't figure out where that variable is supposed
to get populated to determine why it's not.  Any ideas?

Thanks,
-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: gnus-agent-fetch-selected-article

[Kai Großjohann]

David S Goldberg <david.goldberg6@verizon.net> writes:

> A while back Kai (I'm pretty sure) implemented the subject function
> which can be added to gnus-select-article-hook so that all messages
> are downloaded into the agent as they are read.  I really like this
> functionality.  However, after doing a CVS update this morning, it's
> not working.  I edebugged it and it looks like for some reason
> (gnus-agent-method-p gnus-command-method) is returning nil.  Digging
> further I see that gnus-agent-method-p checks the variable
> gnus-agent-covered-methods which is nil.  In the admittedly short time
> I've looked at it, I can't figure out where that variable is supposed
> to get populated to determine why it's not.  Any ideas?

Does it still fail for you?  I've discovered that the +/- indicator
is not updated (I still use my own ?+ hack, instead of the new,
supported, ?O thing), but otherwise it appears to work.

I wonder what does the server buffer say about the servers being
agentized?  I had the problem in the beginning that Gnus would forget
agentizedness twice or thrice.  But now it remembers.
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)