* Never mind @ 1997-05-27 16:11 Lars Magne Ingebrigtsen 1997-05-27 16:24 ` Kai Grossjohann 0 siblings, 1 reply; 14+ messages in thread From: Lars Magne Ingebrigtsen @ 1997-05-27 16:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Never mind 1997-05-27 16:11 Never mind Lars Magne Ingebrigtsen @ 1997-05-27 16:24 ` Kai Grossjohann 1997-05-27 17:50 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 14+ messages in thread From: Kai Grossjohann @ 1997-05-27 16:24 UTC (permalink / raw) >>>>> 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Never mind 1997-05-27 16:24 ` Kai Grossjohann @ 1997-05-27 17:50 ` Lars Magne Ingebrigtsen [not found] ` <x7iv04seu3.fsf@peorth.gweep.net> 1997-05-28 15:43 ` Kai Grossjohann 0 siblings, 2 replies; 14+ messages in thread From: Lars Magne Ingebrigtsen @ 1997-05-27 17:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <x7iv04seu3.fsf@peorth.gweep.net>]
* Re: Never mind [not found] ` <x7iv04seu3.fsf@peorth.gweep.net> @ 1997-05-28 6:37 ` Lars Magne Ingebrigtsen 1997-05-28 7:55 ` Steinar Bang 0 siblings, 1 reply; 14+ messages in thread From: Lars Magne Ingebrigtsen @ 1997-05-28 6:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Never mind 1997-05-28 6:37 ` Lars Magne Ingebrigtsen @ 1997-05-28 7:55 ` Steinar Bang 1997-05-28 9:00 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 14+ messages in thread From: Steinar Bang @ 1997-05-28 7:55 UTC (permalink / raw) >>>>> 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Never mind 1997-05-28 7:55 ` Steinar Bang @ 1997-05-28 9:00 ` Lars Magne Ingebrigtsen [not found] ` <x7vi43dzn2.fsf@peorth.gweep.net> 0 siblings, 1 reply; 14+ messages in thread From: Lars Magne Ingebrigtsen @ 1997-05-28 9:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <x7vi43dzn2.fsf@peorth.gweep.net>]
* Re: Never mind [not found] ` <x7vi43dzn2.fsf@peorth.gweep.net> @ 1997-05-29 7:48 ` Lars Magne Ingebrigtsen [not found] ` <x7u3jmmd1k.fsf@peorth.gweep.net> 0 siblings, 1 reply; 14+ messages in thread From: Lars Magne Ingebrigtsen @ 1997-05-29 7:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <x7u3jmmd1k.fsf@peorth.gweep.net>]
* Re: Never mind [not found] ` <x7u3jmmd1k.fsf@peorth.gweep.net> @ 1997-05-29 21:41 ` Lars Magne Ingebrigtsen 1997-05-30 3:12 ` Don Croyle 0 siblings, 1 reply; 14+ messages in thread From: Lars Magne Ingebrigtsen @ 1997-05-29 21:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Never mind 1997-05-29 21:41 ` Lars Magne Ingebrigtsen @ 1997-05-30 3:12 ` Don Croyle 1997-05-30 20:32 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 14+ messages in thread From: Don Croyle @ 1997-05-30 3:12 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Never mind 1997-05-30 3:12 ` Don Croyle @ 1997-05-30 20:32 ` Lars Magne Ingebrigtsen [not found] ` <wkk9kgijet.fsf@peorth.gweep.net> 0 siblings, 1 reply; 14+ messages in thread From: Lars Magne Ingebrigtsen @ 1997-05-30 20:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <wkk9kgijet.fsf@peorth.gweep.net>]
* Re: Never mind [not found] ` <wkk9kgijet.fsf@peorth.gweep.net> @ 1997-05-31 11:41 ` Lars Magne Ingebrigtsen 0 siblings, 0 replies; 14+ messages in thread From: Lars Magne Ingebrigtsen @ 1997-05-31 11:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Never mind 1997-05-27 17:50 ` Lars Magne Ingebrigtsen [not found] ` <x7iv04seu3.fsf@peorth.gweep.net> @ 1997-05-28 15:43 ` Kai Grossjohann 1997-05-28 17:14 ` Hrvoje Niksic 1 sibling, 1 reply; 14+ messages in thread From: Kai Grossjohann @ 1997-05-28 15:43 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Never mind 1997-05-28 15:43 ` Kai Grossjohann @ 1997-05-28 17:14 ` Hrvoje Niksic [not found] ` <x74tbnbedo.fsf@peorth.gweep.net> 0 siblings, 1 reply; 14+ messages in thread From: Hrvoje Niksic @ 1997-05-28 17:14 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <x74tbnbedo.fsf@peorth.gweep.net>]
* Re: Never mind [not found] ` <x74tbnbedo.fsf@peorth.gweep.net> @ 1997-05-29 7:45 ` Lars Magne Ingebrigtsen 0 siblings, 0 replies; 14+ messages in thread From: Lars Magne Ingebrigtsen @ 1997-05-29 7:45 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~1997-05-31 11:41 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-05-27 16:11 Never mind Lars Magne Ingebrigtsen 1997-05-27 16:24 ` Kai Grossjohann 1997-05-27 17:50 ` Lars Magne Ingebrigtsen [not found] ` <x7iv04seu3.fsf@peorth.gweep.net> 1997-05-28 6:37 ` Lars Magne Ingebrigtsen 1997-05-28 7:55 ` Steinar Bang 1997-05-28 9:00 ` Lars Magne Ingebrigtsen [not found] ` <x7vi43dzn2.fsf@peorth.gweep.net> 1997-05-29 7:48 ` Lars Magne Ingebrigtsen [not found] ` <x7u3jmmd1k.fsf@peorth.gweep.net> 1997-05-29 21:41 ` Lars Magne Ingebrigtsen 1997-05-30 3:12 ` Don Croyle 1997-05-30 20:32 ` Lars Magne Ingebrigtsen [not found] ` <wkk9kgijet.fsf@peorth.gweep.net> 1997-05-31 11:41 ` Lars Magne Ingebrigtsen 1997-05-28 15:43 ` Kai Grossjohann 1997-05-28 17:14 ` Hrvoje Niksic [not found] ` <x74tbnbedo.fsf@peorth.gweep.net> 1997-05-29 7:45 ` Lars Magne Ingebrigtsen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).