bob@tut.cis.ohio-state.edu (Bob Sutterfield) (01/27/88)
Using rn 4.3.1.4, I come upon a newsgroup in which there are some
number N unread articles. I agree that I'd like to read those
articles of interest to me in that newsgroup. rn proceeds to show me
the items in my kill file, and how many articles were killed courtesy
of the existence of that line. This is a wonderful feature! For
example, if some number M unread articles in comp.sources.bugs had
"ethack" in their Subject: lines, each article would be reported as
killed and I wouldn't be bothered to read those articles.
However, my kill file in that newsgroup is very long and "ethack" is
near the top. What if N==M? Even if all N unread articles were
killed fairly early, I am still presented with each other line in my
kill file.
How can I encourage rn to count how many articles have been killed so
far, and if that matches the number of unread articles it saw when I
started that newsgroup, I should go on to the next group without
bothering to check all the rest of the kill file? Is there a macro or
switch or environment variable I'm missing? Is it already changed in
a more recent release than that which I'm running? (point me to it!)
Will it be a new feature in 5.0?
Mind you, Larry, I'm not complaining, just yearning for a bit more
polish on very nice tool. Thanks for any help from anyone!
--
Bob Sutterfield, Department of Computer and Information Science
The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277
bob@ohio-state.{arpa,csnet} or ...!cbosgd!osu-cis!bob
soon: bob@cis.ohio-state.eduwoods@hao.ucar.edu (Greg Woods) (01/28/88)
In article <5365@tut.cis.ohio-state.edu> bob@tut.cis.ohio-state.edu (Bob Sutterfield) writes: >How can I encourage rn to count how many articles have been killed so >far, and if that matches the number of unread articles it saw when I >started that newsgroup, I should go on to the next group without >bothering to check all the rest of the kill file? My observation of how rn works is that the first line in the KILL file takes a while to process, while all the subject lines of unread articles are read in. However, checking each additional line is a relatively fast process since all the article files do not have to be reopened to do this. I think you are worrying about something that is a relatively minor slowdown. --Greg
lwall@devvax.JPL.NASA.GOV (Larry Wall) (01/29/88)
In article <1117@hao.ucar.edu> woods@hao.UUCP (Greg Woods) writes: : In article <5365@tut.cis.ohio-state.edu> bob@tut.cis.ohio-state.edu (Bob Sutterfield) writes: : >How can I encourage rn to count how many articles have been killed so : >far, and if that matches the number of unread articles it saw when I : >started that newsgroup, I should go on to the next group without : >bothering to check all the rest of the kill file? : : My observation of how rn works is that the first line in the KILL file : takes a while to process, while all the subject lines of unread articles : are read in. However, checking each additional line is a relatively fast : process since all the article files do not have to be reopened to do this. : I think you are worrying about something that is a relatively minor slowdown. This is true, as long as you haven't undefined SUBJCACHE to save memory. In the new version of rn, if I ever get a chance to finish it, kill processing is done in a lookahead fashion so that you don't have to wait. Also, all patterns are applied to each article, rather than each pattern applied to all articles, so the aforementioned situation never arises. Larry Wall lwall@jpl-devvax.jpl.nasa.gov
creps@silver.bacs.indiana.edu (Steve Creps) (01/29/88)
In article <1117@hao.ucar.edu> woods@hao.UUCP (Greg Woods) writes: >In article <5365@tut.cis.ohio-state.edu> bob@tut.cis.ohio-state.edu (Bob Sutterfield) writes: >>How can I encourage rn to count how many articles have been killed so >>far, and if that matches the number of unread articles it saw when I >>started that newsgroup, I should go on to the next group without >>bothering to check all the rest of the kill file? > My observation of how rn works is that the first line in the KILL file >takes a while to process, while all the subject lines of unread articles >are read in. However, checking each additional line is a relatively fast >process since all the article files do not have to be reopened to do this. >I think you are worrying about something that is a relatively minor slowdown. It may be a minor slowdown if you're only interested in CPU time, but when you take into consideration having to read it at 1200 baud it isn't so minor. I personally would like to see an option to let you turn off the display of junked articles. (It would reduce the time I spend in rec.arts.startrek by at least 95% :-) ) - - - - - - - - - Steve Creps on the VAX 8650 running Ultrix 2.0-1 at Indiana University. creps@silver.bacs.indiana.edu, ...iuvax!silver!creps, creps@iubacs.bitnet "F-14 Tomcat! There IS no substitute."
woods@hao.ucar.edu (Greg Woods) (01/29/88)
In article <683@silver.bacs.indiana.edu> creps@silver.UUCP (Steve Creps) writes: > It may be a minor slowdown if you're only interested in CPU time, but >when you take into consideration having to read it at 1200 baud it isn't >so minor. I personally would like to see an option to let you turn off >the display of junked articles. Your wish is hereby granted. You can turn on "terse" mode at slow baud rates by using the RNINIT environment variable. Put this line in your .cshrc file (or a similar line in your .profile if you're a Bourne shell user, or however the hell you set environment variables in whatever shell you use :-) setenv RNINIT "+300-2400-t" This will put you into terse mode automatically for speeds from 300-2400 baud. If you don't like environment variables just invoke it as "rn -t" when dialed in at slow speed. You can also delete display of certain header lines at slow speeds, etc. RTFM. --Greg
heiby@falkor.UUCP (Ron Heiby) (01/29/88)
Steve Creps (creps@silver.UUCP) writes: > I personally would like to see an option to let you turn off > the display of junked articles. Steve thinks that the display of junked articles takes too much time on a slow terminal connection. I think so, too. That's why my rn invocations include "-1200-t", which means, "if the bps rate is 1200 or less, then turn on 'terse' mode." I think this will do what Steve wants. It doesn't entirely eliminate the display of junking, but makes it much less verbose. It's nifty! -- Ron Heiby, heiby@mcdchg.UUCP Moderator: comp.newprod & comp.unix "Intel architectures build character."