Re: Suggestion: *Group* SPC to show only new articles?

[Mike McEwan <mike@lotusland.demon.co.uk>]

<jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:

> Gnus must know which articles are new, so building summary based on
> them only should be trivial. And when combined with
> 
>     (gnus-fetch-old-headers nil)
> 
> that'd be the fast access to new articles.
> What gnus functions variables is needed here?

  Well, maybe you didn't see my followup mailing to yours in an earlier 
thread "Marking new unread articles differently?", or maybe you did,
but didn't like what you saw :-). 

  Gnus does *not* know which headers/articles are `new' (here I am
taking `new' to mean headers/articles that have arrived since the last 
time a given group was selected). It only knows which articles are
`unread'. This may suffice for folks that mark everything as `read'
each time they select a group, but this is not the case with me,
particularly where large groups are concerned.

  In order to ascertain what is genuinely `new' since a group was last
selected, you have to have some mechanism of knowing what the last
header/article retrieved for a group was. `new' headers/articles
*only* can then be selected via use of the SELECT-ARTICLES argument to 
`gnus-group-read-group'. Just selecting a number of `new'
headers/articles does not always do it where real newsgroups are
concerned as some articles may have been cancelled and you get `old'
non-new articles in their place.

  I'm still tweaking with the patch I mailed on the above-mentioned
thread, but generally everything works just fine. Lars has said he
will not consider such new function until we're into the `pgnus'
cycle, at which time I'll re-mail what I have to this group. In the
meantime I'm using CVS to re-merge my patch with each release of
gnus (I like that CVS), there aren't enough hooks to keep the code
isolated.

  If you really did miss my previous mailing, and want, I'll mail my
current patch to you. If not, and you don't, I'll understand :-).

-- 
Mike.