Another agent problem

Another agent problem

[Kai Großjohann]

Look at this snippet from gnus-agent-fetch-headers:

    ;; Remove known articles.
    (when (gnus-agent-load-alist group)
      (setq articles (gnus-list-range-intersection
		      articles
		      (list
		       (cons (1+ (caar (last gnus-agent-article-alist)))
			     (cdr (gnus-active group)))))))

Now gnus-agent-article-alist usually start with entries like (42 .
t), and ends with some entries like (43) (or (43 . nil), I guess).  I
think this comes from the fact that the agent now fetches all headers
at all times.

So the cons statement usually returns something like (4712 . 4711)
where 4711 is the last article number in the group, which also
happens to be the last entry from gnus-agent-article-alist.

And gnus-list-range-intersection always returns nil if there is a
range (a . b) such that a > b holds.

Hm.  Maybe the problem is in gnus-list-range-intersection.  It should
interpret a range like this as empty, I think.

Or should the above snippet be fixed such that it does not try to
build such strange ranges?

Does anyone know how to fix this?

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

Re: Another agent problem

[Kai Großjohann]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Now gnus-agent-article-alist usually start with entries like (42 .
> t), and ends with some entries like (43) (or (43 . nil), I guess).  I
> think this comes from the fact that the agent now fetches all headers
> at all times.
>
> So the cons statement usually returns something like (4712 . 4711)
> where 4711 is the last article number in the group, which also
> happens to be the last entry from gnus-agent-article-alist.
>
> And gnus-list-range-intersection always returns nil if there is a
> range (a . b) such that a > b holds.
>
> Hm.  Maybe the problem is in gnus-list-range-intersection.  It should
> interpret a range like this as empty, I think.
>
> Or should the above snippet be fixed such that it does not try to
> build such strange ranges?

As a preliminary measure, I've now changed the snippet, and this
seems to have done the trick.  Phew.

I'd appreciate if somebody could help to find the proper solution.

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