Re: Agent gone mad?

[kai.grossjohann@uni-duisburg.de (Kai Großjohann)]

Henrik Enberg <henrik@enberg.org> writes:

> kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:
>
>> Henrik Enberg <henrik@enberg.org> writes:
>>
>>> Running the below function to mimic the behaviour in the above code, I
>>> always get "high" as 1 less than "low", so the when clause will never
>>> be executed.
>>>
>>> (defun high/low ()
>>>   (interactive)
>>>   (let ((low (1+ (caar (last gnus-agent-article-alist))))
>>> 	(high (cdr (gnus-active gnus-newsgroup-name))))
>>>     (message "high = %s, low = %s" high low)))
>>
>> Gah?
>
> Hmm, what do you get?
>
> [...]

I didn't try the function, but I also got low = high + 1 when I used
the debugger.

The "gah" meant that I don't know why the original code works for
you.  It should fail!

>> Okay, so to summarize: when you remove the when condition, Gnus is
>> quick again.
>>
>> But that's because it retrieves no articles, because
>> gnus-list-range-intersection returns nil.
>>
>> So I'm not sure it's a good idea to remove the condition.
>
> No,  Gnus _does_ retrive articles when I remove the condition.  It even
> works as I think you intended it.  Old style behaviour when
> gnus-agent-consider-all-articles is nil, and all articles when it is t.

Strange.

>> But I don't believe you were happy with the previous agent behavior
>> if it never retrieved any articles.  So how about you go back to the
>> gnus-agent version before my messing around with it and see if that
>> retrieves any articles at all, and also examine the situation in the
>> code we're talking about.
>
> Ok, I tried to check out the version from the 17th.  It works just like
> it always has, retrieving only new articles and headers.
>
>> Maybe I did something wrong when changing the code.
>
> It just might me my Gnus that is screwed up, but I tried to subscribe
> to a new group I've never subscribed to before.  And it gave me the
> same behaviour as all my other groups.

Okay, now we need to verify:

Usually, low is greater than high.  You verified this already,
check.  When this happens, gnus-list-range-intersection returns nil.
Right?  So then `articles' will be nil.  Right?

So Gnus only fetches articles which are explicitly marked for
download.  Right?

Since we have now reached a contradiction, one of the checks above
must fail.  But which one?

> A final note.  I may have to turn in my geek badge, but I can't work
> out how to edebug a Gnus function.  Say I instrument
> gnus-agent-retrieve-headers, how do I step through it?

With point inside the function, hit M-x edebug-defun RET.  Then you
should either arrange for the buffer to be well visible in a frame,
or you should bury the buffer (then edebug will display it in the
current frame).  Then you just do something that invokes the
function.  Then you can use SPC to step through it and e to eval Lisp
expressions (and the menu).

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)