Never mind

Never mind

[Lars Magne Ingebrigtsen]

The mode line problem has disappeared.  I must have been doing
something odd.

Anyways -- the Gnus agent will always download headers, but only the
articles that the user has requested (in one way or the other).  How
should Gnus display these non-fetched articles in the summary buffer?
They must be displayed, because the user must have the opportunity to
mark them as downloadable manually.  Should they be marked as read
automatically, though?  Otherwise all the article selection commands
will be kinda funky -- `n' will try to select these articles, which
will lead to Gnus beeping "Article canceled" or something.

Yes, they should probably be marked as read with some special mark --
"H", for instance.  (For "header only".)

The Gnus agent does its crossposting thing by looking at the Xrefs
header from the server.  But many servers do not include an Xrefs
header in the NOV databases.  So how should this be handled?  Gnus
doesn't know by itself what article number the crossposted instances
of the articles will have in the other groups.  Hm.  Perhaps Gnus
should just do an xhdr to get the Xrefs header.  Which will be
slowish, but...

Gah!  I'm so stupid.  I don't need to know the Xrefs header before
actually downloading the article, and after downloading the article I
do have the Xrefs header.

Never mind.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Magne Ingebrigtsen

Re: Never mind

[Kai Grossjohann]

>>>>> Lars Magne Ingebrigtsen writes:

  Lars> Anyways -- the Gnus agent will always download headers, but
  Lars> only the articles that the user has requested (in one way or
  Lars> the other).  How should Gnus display these non-fetched
  Lars> articles in the summary buffer?  They must be displayed,
  Lars> because the user must have the opportunity to mark them as
  Lars> downloadable manually.  Should they be marked as read
  Lars> automatically, though?  Otherwise all the article selection
  Lars> commands will be kinda funky -- `n' will try to select these
  Lars> articles, which will lead to Gnus beeping "Article canceled"
  Lars> or something.

Hm.  I'm not sure I understand what you're doing.  But the way I see
it is like this:

  - User starts PPP and dials the ISP
  - User starts Emacs, starts Gnus
  - User marks articles for download
  - User invokes download command
  - Gnus downloads articles
  - User hangs up phone, maybe exits Gnus
  - User looks at downloaded articles

IMHO no article should be considered as read until the user has looked
at the downloaded copy.

But then, maybe you're doing something different entirely and I just
haven't been paying attention when you explained about nnagent back
when.

kai
-- 
Life is hard and then you die.

Re: Never mind

[Lars Magne Ingebrigtsen]

Kai Grossjohann <grossjohann@ls6.cs.uni-dortmund.de> writes:

> Hm.  I'm not sure I understand what you're doing.  But the way I see
> it is like this:
> 
>   - User starts PPP and dials the ISP
>   - User starts Emacs, starts Gnus
>   - User marks articles for download
>   - User invokes download command
>   - Gnus downloads articles
>   - User hangs up phone, maybe exits Gnus
>   - User looks at downloaded articles

Yes.  Except for the "starts Emacs, starts Gnus" and especially the
"exits Gnus" parts.  You should *never* do that.  *Ever*.  :-)

> IMHO no article should be considered as read until the user has looked
> at the downloaded copy.

I was thinking aloud about what to do with articles that the user has
decided not to download.  Because they are spam, or are too big, or
has a low score, or has bad hair.  I think they should be marked as
read upon group entry so that they are displayed (and the user can
mark them as downloadable so they'll be fetched at next download
time), but won't get in they way of normal reading.

I guess this means that the mark-as-downloadable command has to mark
the articles as unread, though.

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

Re: Never mind

[Lars Magne Ingebrigtsen]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> A new type of tick mark, "marked for download" should be created.  Setting
> this mark on an article will put it in line to be retrieved from the
> server;

Yes, this is implemented.

> setting this mark on a group (in the group buffer) will cause all
> articles in the group to be marked for download.

Uhm...  This would be for groups that aren't usually covered by the
agent, I guess?

The Gnus agent now works on a virtual server basis.  You go to the
server buffer and add the servers you want to the agent.  Then (the
next time you ask it to download) it'll do all the groups belonging to
those servers.

> The scoring routines or an extension thereof should be capable of
> setting this mark in some fashion.

I don't see why.  If you want downloading based on scoring, you just
use the agent scoring mechanism.

> It should *NOT* be tied to the 'D' key in any fashion. :) How about
> '@'?

I've added a tertiary mark that's bound to `J #'.  (All the agent
commands in all buffers are on the `J' submap.)

> Some means of readilly distinguishing downloaded messages from those for
> which only headers exist locally needs to be created, even on displays
> incapable of color or font changes.

Yes.  The way it does this now is by marking the undownloaded articles
as read.

> It should also be possible to "clump" downloaded articles at the top
> (or bottom, or maybe wherever) of the summary buffer, optionally
> overriding threading.

I think that wouldn't be very useful.

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

Re: Never mind

[Steinar Bang]

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

>>>>> Stainless Steel Rat <ratinox@peorth.gweep.net>:

>> I dislike the concept of automatically marking anything as read
>> unless the reader has explicitly done something to cause that to
>> happen.

[snip!]

>> Some means of readilly distinguishing downloaded messages from those for
>> which only headers exist locally needs to be created, even on displays
>> incapable of color or font changes.

> Yes.  The way it does this now is by marking the undownloaded articles
> as read.

Hm... I agree with Rich, in disliking this approach (I mean: they
*aren't* actually read...), but I don't really have a constructive
solution, except to suggest yet another tick mark.

>> It should also be possible to "clump" downloaded articles at the top
>> (or bottom, or maybe wherever) of the summary buffer, optionally
>> overriding threading.

> I think that wouldn't be very useful.

Having them clumped, and visually separate, would be very useful when
your walking through them, and decide which to down load.  They could
enter their normal threading position, after downloading.

Re: Never mind

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@metis.no> writes:

> > Yes.  The way it does this now is by marking the undownloaded articles
> > as read.
> 
> Hm... I agree with Rich, in disliking this approach (I mean: they
> *aren't* actually read...), but I don't really have a constructive
> solution, except to suggest yet another tick mark.

Well, perhaps.  They could me marked with, uhm, "@" (which would be
"unread" in the manner of "!").  Article selection commands would skip
past these articles, just as they do with "!".  Yup, I think I'll do
that. 

> Having them clumped, and visually separate, would be very useful when
> your walking through them, and decide which to down load.  They could
> enter their normal threading position, after downloading.

Well, if we have this situation:

    [  21: Paul Stodghill      ] Bug with gnus-group-jump-to-group and topics
@       [ 1035: Hrvoje Niksic       ] 
            [  21: Paul Stodghill      ] 

(Hrvoje's article wasn't downloaded because it was too long.)  Why
would you want to break threading and put that article in the top (or
somewhere) of the summary buffer?  Having these @ articles in the
thread doesn't impede normal reading, and would give us more
information whether to download the article or not than when displayed
outside the thread.

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

Re: Never mind

[Lars Magne Ingebrigtsen]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> Lars>     [  21: Paul Stodghill      ] Bug with gnus-group-jump-to-group ...
> Lars> @       [ 1035: Hrvoje Niksic       ] 
> Lars>             [  21: Paul Stodghill      ] 
> 
> It is a matter of degree.  Given a summary buffer with a few articles that
> have been downloaded and a lot that have not (for whatever reason), and
> given that agent is not going to mark as read articles that I belive should
> not be marked as read, being able to cluster together articles that have
> been downloaded and those that have been marked for downloading would be a
> win sufficient to offset the "ugliness" of breaking threads.

The "@" here means that it has not been downloaded; not that it has
been marked for downloading.

Uhm -- or do you mean that the non-downloaded, the
marked-for-dowloading, and the downloaded articles should each form a
separate clump of articles?

> Either way, it might also be a win to automatically @ mark articles that
> have not been downloaded that one attempts to select while the agent is in
> offline mode.

Yes, probably.

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

Re: Never mind

[Lars Magne Ingebrigtsen]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> Lars> The "@" here means that it has not been downloaded; not that it has
> Lars> been marked for downloading.
> 
> Okay, I think I see the problem, and it hinges on different ideas on how an
> offline news reader should work.  Articles to be downloaded should both be
> marked for downloading manually as well automatically.  This is the way
> most (if not all) offline newsreaders operate, and it will work for Gnus
> with the least amount of alteration to how Gnus functions.
> 
> So...
> 
> Gnus retrieves header information for groups for which automatic marking
> for download is to be performed.  Articles to be automatically downloaded
> are mrked for downloading (@).  Such @-marked articles may be downloaded at
> this time, either by automatic or manual invocation of the agent.

No -- I think I must have problems putting these concepts into words,
for some reason.

This is how it works:

You set up Gnus as a normal, online-reading newsreader -- the way you
do today.  You fiddle until you are happy with how it works.  Then you
decide that you want to read articles offline.

You then press a few magic keys to tell Gnus which servers are to be
covered.  You press `J s' to download all the headers to all the
groups from these servers, and some articles from some of the groups
from these servers (and which articles to be downloaded is, of course,
customizable in a gazillion ways (this is Gnus, after all)).  You then
press `J j' (which toggles online/offline.)  You then hang up the
modem and keep on reading.  You won't notice anything different -- all
commands work as before.

When you want to rescan news, you connect the modem, `J j', `g',
`J s', and hang up the modem and press `J j'.  Repeat.  Repeat.
Repeat. 

The issue here is what to do about articles in groups covered by the
agent that you have chosen not to download.  These articles will be
displayed in the summary buffer (since the agent always fetches all
headers to all the groups).  These articles will be marked with "@" in
the first column, and normal reading commands will skip past them,
just like "!"-marked articles.  To mark these as downloadable, you use
the `@' command, which will set an "X" mark in the third column.
(Perhaps this should be the other way around, or something.)

> User may select groups at this time.  Summary buffers may cluster articles
> that have been @-marked and downloaded in a convenient fashion much as how
> low-scored but not expunged articles are clustered when sorting by score,
> or not, at the user's convenience.  Better still... Gnus will be required
> to keep a list of articles in each group that are @-marked and downloaded.
> Hiding and unhiding all the articles that are not in either of these lists
> is probably easier to accomplish than weird-assed pseudo-sorting algorithms.

Again, I don't see why clumping together undowloaded articles in the
summary buffer would be useful.  You'd almost have to switch off
threading to have that happen reliably, which is why sorting on score
is so worthless.

> Gnus' behaviour when selecting articles that have not been
> downloaded depends on the agent's current operating mode.  If the
> agent is in online mode the article will be downloaded immediately,
> regardless of @ marks (the @ mark will be cleared if it is set and
> the article is downloaded).

When Gnus is online, the agent doesn't do anything.  It's (for all
intents and purposes) non-existent, expect for the `J s' (etc.)
commands. 

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

Re: Never mind

[Don Croyle]

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

> This is how it works:
> 
> You set up Gnus as a normal, online-reading newsreader -- the way you
> do today.  You fiddle until you are happy with how it works.  Then you
> decide that you want to read articles offline.
> 
> You then press a few magic keys to tell Gnus which servers are to be
> covered.  You press `J s' to download all the headers to all the
> groups from these servers, and some articles from some of the groups
> from these servers (and which articles to be downloaded is, of course,
> customizable in a gazillion ways (this is Gnus, after all)).  You then
> press `J j' (which toggles online/offline.)  You then hang up the
> modem and keep on reading.  You won't notice anything different -- all
> commands work as before.

Ok, I think I see the paradigm that you're working from.  Basically
the way that you're setting it up Gnus downloads everything that you
might reasonably want to read and becomes its own news server.  Yhis
is a one long pass approach, with a possible second pass to pick up
stuff that wasn't pulled down automatically.  QWK readers tend to work
this way, if I remember correctly.

The approach I'm used to seeing in an offline/disconnected reader is a
two pass approach.  First pass is a quick run through to grab headers,
second pass downloads whatever the user has specifically decided to
read.  This is the approach that I'm used to from TapCIS and OzCIS
(Compuserve specific offline readers) as well as Forte Agent.

With the two pass approach you control fairly exactly what gets
downloaded; with the one pass approach it just sort of happens.  The
two pass method is less transparent and requires more effort on the
part of the user, but it's more efficient.  Since my offline reading
habits were formed back when I was paying Compuserve US$12.50/hour for
2400 baud and storing things on 720K floppies, I've got a bias towards
efficiency.  YMMV.
-- 
I've always wanted to be a dilettante, but I've never quite been ready
to make the commitment.

Re: Never mind

[Lars Magne Ingebrigtsen]

Don Croyle <croyle@gelemna.ft-wayne.in.us> writes:

> Ok, I think I see the paradigm that you're working from.  Basically
> the way that you're setting it up Gnus downloads everything that you
> might reasonably want to read and becomes its own news server.

Well, if you want it to.  You can set it to download nothing but
headers if you don't want that.  You can then mark articles manually
for downloading.

However, I've always been of the opinion that using computers should
mean having to do less manual labor, not more.  So enabling Gnus to
empower users to set Gnus up to do things without any human
intervention is very important to me.

Gnus will basically work as Free Agent works -- only with a wider
range of methods (using artificial stupidity) for deciding what
articles to download automatically.

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

Re: Never mind

[Lars Magne Ingebrigtsen]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> Lars> Gnus will basically work as Free Agent works -- only with a wider
> Lars> range of methods (using artificial stupidity) for deciding what
> Lars> articles to download automatically.
> 
> Maybe... but I still think that the concept of a "marked as downloadable"
> tick-like mark is the best way to accomodate everyone since such a mark may
> be set both automatically and manually.  If you go through my last
> description of they way I think it should work you will see that both ways
> of reading and downloading are available simultaneousy, without any
> significant degree of changes to the way Gnus functions.  Everybody wins.

Well, we do have a downloadable mark.

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

Re: Never mind

[Kai Grossjohann]

  Kai> IMHO no article should be considered as read until the user has looked
  Kai> at the downloaded copy.

  Lars> I was thinking aloud about what to do with articles that the
  Lars> user has decided not to download.  Because they are spam, or
  Lars> are too big, or has a low score, or has bad hair.  I think
  Lars> they should be marked as read upon group entry so that they
  Lars> are displayed (and the user can mark them as downloadable so
  Lars> they'll be fetched at next download time), but won't get in
  Lars> they way of normal reading.

There should be a new mark for that.  Which behaves like the dormant
mark, somewhat.  But it should be distinct, so that "/ m" works.

Whatcha think?

kai
-- 
Life is hard and then you die.

Re: Never mind

[Hrvoje Niksic]

Kai Grossjohann <grossjohann@charly.cs.uni-dortmund.de> writes:

>   Kai> IMHO no article should be considered as read until the user has looked
>   Kai> at the downloaded copy.
> 
>   Lars> I was thinking aloud about what to do with articles that the
>   Lars> user has decided not to download.  Because they are spam, or
>   Lars> are too big, or has a low score, or has bad hair.  I think
>   Lars> they should be marked as read upon group entry so that they
>   Lars> are displayed (and the user can mark them as downloadable so
>   Lars> they'll be fetched at next download time), but won't get in
>   Lars> they way of normal reading.
> 
> There should be a new mark for that.

I don't think it would be wise to waste resources (in .newsrc.eld) for 
marking of spams/low-scores/bad-hairs.  If I don't want it, then it's
read.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Ask not for whom the <CONTROL-G> tolls.

Re: Never mind

[Lars Magne Ingebrigtsen]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> Some means of easilly distinguishing an article that has been retrieved
> might be useful; storing a flag in .newsrc.eld is probably the most
> effective way to do this. 

The agent stores this information elsewhere, so having it in the
.newsrc.eld as well isn't necessary.

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