Re: two agent nits

[Kevin Greiner <kgreiner@xpediantsolutions.com>]

Simon Josefsson <jas@extundo.com> writes:

> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>
>> Simon Josefsson <jas@extundo.com> writes:
>>
>>> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>>>
>>>> Simon Josefsson <jas@extundo.com> writes:
>>>>
>>>>> * I can't seem to get the agent to fetch read articles.
>>>>>   gnus-agent-consider-all-articles's value is t
>>>>>   The default agent category predicate is 'true'.
>>>>>   `J s' and `J u' just download unread or ticked articles.
>>>>
>>>> Have to tried setting gnus-agent-consider-all-articles to nil?  That
>>>> seems to work for me.
>>>
>>> I tried, but still the same.  Pressing `J u' on groups just say it is
>>> finished, but only the unread/ticked articles are in my local cache.
>>>
>>> Hm.  The manual and the docstring for the variable doesn't seem to be
>>> in sync.  I thought the variable did what the docstring said, but the
>>> manual just discuss missing headers.  Which one is correct?
>>
>> The variable gnus-agent-consider-all-articles appears in
>> gnus-agent-fetch-headers but NOT gnus-agent-fetch-articles.  However,
>> gnus-agent-fetch-group-1 calls gnus-agent-fetch-headers to get the
>> list of new articles so gnus-agent-consider-all-articles may, by
>> modifying the return value of gnus-agent-fetch-headers, effect the
>> list of articles being fetched by gnus-agent-fetch-articles.
>
> Thanks for the pointers, I think I isolated the problem, from g-a-f-a:
>
>   (let* ((fetch-all (and gnus-agent-consider-all-articles
>                          ;; Do not fetch all headers if the predicate
>                          ;; implies that we only consider unread articles.
>                          (not (gnus-predicate-implies-unread
>                                (gnus-agent-find-parameter group
>                                                           'agent-predicate)))))
>
> Fetch-all evaluate to nil for me, causing the function to only return
> a list of unread articles.  Since g-a-c-a-a is t, the reason fetch-al
> is nil is because of the second statement.
>
> (gnus-predicate-implies-unread 'true)
>  => ignore
>
> (not (gnus-predicate-implies-unread 'true))
>  => nil
>
> Reading the docstring:
>
> (gnus-predicate-implies-unread PREDICATE)
>   Say whether PREDICATE implies unread articles only.
>   It is okay to miss some cases, but there must be no false positives.
>   That is, if this function returns true, then indeed the predicate must
>   return only unread articles.
>
> The 'ignore return value is not documented, and because it is non-nil
> it is treated as true by the caller in this case.
>
> If I apply this change, everything works, but I can't tell if it is
> the right thing.

Thanks for isolating the problem.  I'm also not certain that this is
the right thing to do.  It is certainly the correct answer if the
function is gnus-agent-true but what if the function is a compiled
function returned by gnus-category-make-function?

> --- gnus-agent.el.~6.180.~	2003-12-01 12:35:54.000000000 +0100
> +++ gnus-agent.el	2003-12-01 17:39:06.000000000 +0100
> @@ -2455,7 +2455,7 @@
>          ((not function)
>           nil)
>          ((functionp function)
> -         'ignore)
> +	 nil)
>          ((memq (car function) '(or and not))
>           (apply (car function)
>                  (mapcar 'gnus-function-implies-unread-1 (cdr function))))


> Now, continuing, I found that most of my groups had .agentviews
> looking like:
>
> ((731544 66) (731540 64 . 65) ...
> 2
>
> I.e., they have large integers in them, which look like corruption.

That isn't corruption.  The large numbers are the timestamps when the
articles were fetched.  The original format looked like
((66 . 731544) (64 . 731540) (65 . 731540)) but it was slow to load
for large groups as it repeated the large numbers endlessly.  The
gnus-agent-load-alist function now loads either format and converts
internally to the alist form.

Kevin