agent-fetching messing with the "first" unread article

agent-fetching messing with the "first" unread article

[David S Goldberg]

Running a CVS update from Mon Jan  6 10:35:29 2003 EST

Ever since the summary line update code was added to
gnus-agent-fetch-selected-article, which I added to
gnus-select-article-hook like so:

(add-hook 'gnus-select-article-hook
	  (lambda ()
	    (if (eq (car (gnus-find-method-for-group
			  gnus-newsgroup-name))
		    'nnimap)
		(gnus-agent-fetch-selected-article))))

I find that gnus-summary-first-unread-article no longer works as I
expect.  I enter a group and see a nice threaded display with the
threads sorted more or less by date.  I press `.' and get to the first
new article in the first thread shown in the display (I fetch earlier
articles so some old ones are showing too).  I get a message about the
article being fetched and the summary line is updated to indicate the
article is now in the agent.  In the summary, there is another unread
article immediately below the one I am now reading.  I press `.' again
expecting to go to that article.  Instead I am jumped to an article in
a completely different thread.  Removing the above hook fixes the
problem for me.

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

Re: agent-fetching messing with the "first" unread article

[Kai Großjohann]

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

> I press `.' and get to the first new article in the first thread
> shown in the display (I fetch earlier articles so some old ones are
> showing too).  I get a message about the article being fetched and
> the summary line is updated to indicate the article is now in the
> agent.  In the summary, there is another unread article immediately
> below the one I am now reading.  I press `.' again expecting to go
> to that article.  Instead I am jumped to an article in a completely
> different thread.  Removing the above hook fixes the problem for me.

In gnus-agent-fetch-selected-article, there is a call to
gnus-summary-update-article.  What happens when you remove that (or
comment it out)?  Does that change the behavior?
-- 
Ambibibentists unite!

Re: agent-fetching messing with the "first" unread article

[David S Goldberg]

>>>>> On Tue, 07 Jan 2003 19:07:16 +0100, kai.grossjohann@uni-duisburg.de (Kai Großjohann) said:

> In gnus-agent-fetch-selected-article, there is a call to
> gnus-summary-update-article.  What happens when you remove that (or
> comment it out)?  Does that change the behavior?

That appears to be it.  I changed gnus-summary-update-article to
gnus-summary-update-line.  It looks like the former does some stuff
with a thread list whereas the latter just regenerates based on
gnus-summary-line-format.  I haven't had enough mail in the mean time
to be sure, but so far the change seems to have worked.  I'm not sure
if it would break anything else, though.

-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: agent-fetching messing with the "first" unread article

[David S Goldberg]

>>>>> On Tue, 07 Jan 2003 16:29:48 -0500, David S Goldberg <david.goldberg6@verizon.net> said:

>>>>> On Tue, 07 Jan 2003 19:07:16 +0100, kai.grossjohann@uni-duisburg.de (Kai Großjohann) said:
>> In gnus-agent-fetch-selected-article, there is a call to
>> gnus-summary-update-article.  What happens when you remove that (or
>> comment it out)?  Does that change the behavior?

> That appears to be it.  I changed gnus-summary-update-article to
> gnus-summary-update-line.  It looks like the former does some stuff
> with a thread list whereas the latter just regenerates based on
> gnus-summary-line-format.  I haven't had enough mail in the mean time
> to be sure, but so far the change seems to have worked.  I'm not sure
> if it would break anything else, though.

What it broke was the reason for putting the funcall in there in the
first place :-) Fortunately there's another option:
gnus-summary-update-download-mark.  This appears to work without
mucking with the thread info.  That's with a minimal amount of mail to
test with so far, though.

-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: agent-fetching messing with the "first" unread article

[Lars Magne Ingebrigtsen]

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

>> That appears to be it.  I changed gnus-summary-update-article to
>> gnus-summary-update-line.

[...]

> What it broke was the reason for putting the funcall in there in the
> first place :-) Fortunately there's another option:
> gnus-summary-update-download-mark.  This appears to work without
> mucking with the thread info.  That's with a minimal amount of mail to
> test with so far, though.

Looking at the CVS, `gnus-summary-update-download-mark' is what used
to be there, and that didn't work, which is why
`gnus-summary-update-article' was used instead.

I've now changed it to use `gnus-summary-update-line' instead...

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: agent-fetching messing with the "first" unread article

[Kai Großjohann]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Looking at the CVS, `gnus-summary-update-download-mark' is what used
> to be there, and that didn't work, which is why
> `gnus-summary-update-article' was used instead.

Yes.  The %O spec wasn't updated with
gnus-summary-update-download-mark (despite the name of the
function...).  But the color did change.

I'll try the new version when I'm back online.
-- 
Ambibibentists unite!

Re: agent-fetching messing with the "first" unread article

[kgreiner]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> David S Goldberg <david.goldberg6@verizon.net> writes:
>
>>> That appears to be it.  I changed gnus-summary-update-article to
>>> gnus-summary-update-line.
>
> [...]
>
>> What it broke was the reason for putting the funcall in there in the
>> first place :-) Fortunately there's another option:
>> gnus-summary-update-download-mark.  This appears to work without
>> mucking with the thread info.  That's with a minimal amount of mail to
>> test with so far, though.
>
> Looking at the CVS, `gnus-summary-update-download-mark' is what used
> to be there, and that didn't work, which is why
> `gnus-summary-update-article' was used instead.
>
> I've now changed it to use `gnus-summary-update-line' instead...
>

Try replacing
	(gnus-summary-update-article gnus-current-article)

with
	(gnus-summary-update-article-line gnus-current-article
         (gnus-summary-article-header gnus-current-article))
in gnus-agent-fetch-selected-article.

it seems to work for me.

Kevin

Re: agent-fetching messing with the "first" unread article

[David S Goldberg]

>>>>> On Wed, 08 Jan 2003 00:28:16 -0600, kgreiner@xpediantsolutions.com said:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> [...]
>> I've now changed it to use `gnus-summary-update-line' instead...
>> 

> Try replacing
> 	(gnus-summary-update-article gnus-current-article)

> with
> 	(gnus-summary-update-article-line gnus-current-article
>          (gnus-summary-article-header gnus-current-article))
> in gnus-agent-fetch-selected-article.

Yes, this seems to work the best.  Both gnus-summary-update-line and
gnus-summary-update-download-mark only worked sporadically this
morning on a largish summary buffer (55 new articles from the ding
list).

-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: agent-fetching messing with the "first" unread article

[Lars Magne Ingebrigtsen]

kgreiner@xpediantsolutions.com writes:

> Try replacing
> 	(gnus-summary-update-article gnus-current-article)
>
> with
> 	(gnus-summary-update-article-line gnus-current-article
>          (gnus-summary-article-header gnus-current-article))
> in gnus-agent-fetch-selected-article.

Ok; I've now done that.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: agent-fetching messing with the "first" unread article

[kgreiner]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> Looking at the CVS, `gnus-summary-update-download-mark' is what used
>> to be there, and that didn't work, which is why
>> `gnus-summary-update-article' was used instead.
>
> Yes.  The %O spec wasn't updated with
> gnus-summary-update-download-mark (despite the name of the
> function...).  But the color did change.
>
> I'll try the new version when I'm back online.

Well, I must have fixed a bug along the way because
gnus-summary-update-download-mark works now (At least for me).

If you can confirm that using (gnus-summary-update-download-mark
gnus-current-article) in gnus-agent-fetch-selected-article updates
both the color and %O spec, I'll check it in today.

Kevin

Re: agent-fetching messing with the "first" unread article

[David S Goldberg]

>>>>> On Wed, 08 Jan 2003 10:16:25 -0600, kgreiner@xpediantsolutions.com said:

> kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> If you can confirm that using (gnus-summary-update-download-mark
> gnus-current-article) in gnus-agent-fetch-selected-article updates
> both the color and %O spec, I'll check it in today.

It only worked sporadically for me.  It didn't update every message
and in a couple cases, found a - earlier in the line and updated that
instead of the one in the actual position I specified for %O.  Your
earlier suggestion of gnus-update-article-line, which Lars checked in
a bit earlier today is working much more reliably.  I haven't seen it
miss yet.

-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: agent-fetching messing with the "first" unread article

[kgreiner]

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

>>>>>> On Wed, 08 Jan 2003 10:16:25 -0600, kgreiner@xpediantsolutions.com said:
>
>> kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:
>
>> If you can confirm that using (gnus-summary-update-download-mark
>> gnus-current-article) in gnus-agent-fetch-selected-article updates
>> both the color and %O spec, I'll check it in today.
>
> It only worked sporadically for me.  It didn't update every message
> and in a couple cases, found a - earlier in the line and updated that
> instead of the one in the actual position I specified for %O.  Your
> earlier suggestion of gnus-update-article-line, which Lars checked in
> a bit earlier today is working much more reliably.  I haven't seen it
> miss yet.

Thanks, rather disturbing news.  gnus-summary-update-download-mark
calls gnus-summary-update-mark to do the actual update.  By your
description, something is seriously wrong in a basic utility function
:(.  At least, gnus-update-article-line works.

Kevin

Re: agent-fetching messing with the "first" unread article

[Lars Magne Ingebrigtsen]

kgreiner@xpediantsolutions.com writes:

> Thanks, rather disturbing news.  gnus-summary-update-download-mark
> calls gnus-summary-update-mark to do the actual update.  By your
> description, something is seriously wrong in a basic utility function
> :(.  At least, gnus-update-article-line works.

`gnus-summary-update-download-mark' is a very lightweight function
that just updates the mark -- it isn't really meant to update the
rest of the line.

(Many of the other update-*-mark commands work the same way.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: agent-fetching messing with the "first" unread article

[kgreiner]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> kgreiner@xpediantsolutions.com writes:
>
>> Thanks, rather disturbing news.  gnus-summary-update-download-mark
>> calls gnus-summary-update-mark to do the actual update.  By your
>> description, something is seriously wrong in a basic utility function
>> :(.  At least, gnus-update-article-line works.
>
> `gnus-summary-update-download-mark' is a very lightweight function
> that just updates the mark -- it isn't really meant to update the
> rest of the line.
>

True.  All that I wanted it to do was change the undownloaded(-) mark
to a downloaded(+) mark.  Dave claimed that
gnus-summary-update-download-mark changed the wrong minus(-) in the
line.

Kevin