[comp.sources.d] lots of trn problems

sef@kithrup.com (Sean Eric Fagan) (12/29/90)

I finally had some time to play with the stuff at work.

The second posting was a lot easier, after I was told how to use it (i.e.,
unpack part 9, unpack the *second* part 9, unpack the second part 10, then
unpack parts 11-14).

One of the problems I mentioned, about trn dumping core, I finally found the
cause of.  It was the person who'd ported the NNTP library, and had not
quite realized what the term 'bounds checking' means (as a result, I ended
up with a return address of 'prin' 8-().

I'm still haggling with the mthreads stuff; seems it doesn't work too well
with nntp.  But, as I said, I'm playing with it, and am trying to come up
with an invocation that will work properly.

Meanwhile, at home, I haven't upgraded, because I haven't felt the need
(yet?).  It works fine at home (except for a couple of quirks I'll mention
below), and I'm very satisfied with it.  Actually, I'm addicted to it... 8-)

The quirks I mentioned above:  as I mentioned before, trn seems to go
through the threads backwards.  That is, the first article it deals with is
the last article in the group.  It seems to deal with articles within
threads properly, so this isn't a major problem, just a minor annoyance.
(For example, if there are four threads in comp.unix.internals, with 1, 3,
2, and 9 articles in each respective thread [in that order, as well], then
the only article in thread a appears to be the last article available in the
group.)  This seems to be happening with both the older version at home and
the newer version at work.  Again, it's just a minor annoyance.

The next problem is when I notice that I want to read an article again,
after I've left the group.  Say that I've only looked at the thread
selection menu, and didn't think there was anything I wanted to read.  So I
type 'q' (to get to the 'What next? [ynq]' prompt), and then 'c' (for
catchup), and 'y' (to confirm).  When I get to the next group, and decide I
really did want to read one of the articles in the previous group, it's
somewhat difficult finding the article.  If I just go to the last article,
and use 'P' to go through the articles, it does not go in a normal means.
(I think it's following the threads backwardsly.  This doesn't work very
well, though!)

Anyway, again, in case the author reads news (since I still have yet to get
a reply to any of my messages), I *do* like trn; I don't know how I lived
without it, now.  But it's not perfect, and it still had one of the worst
original distributions I've ever seen on c.s.u.

-- 
Sean Eric Fagan  | "I made the universe, but please don't blame me for it;
sef@kithrup.COM  |  I had a bellyache at the time."
-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.

ed@dah.sub.org (Ed Braaten) (12/29/90)

sef@kithrup.com (Sean Eric Fagan) writes:

>I'm still haggling with the mthreads stuff; seems it doesn't work too well
>with nntp.  But, as I said, I'm playing with it, and am trying to come up
>with an invocation that will work properly.

I also had a lot of trouble getting trn to run, and (between core dumps)
I didn't really like the interface much.  I don't understand all the fuss
over trn.  I find that nn is much more robust and if I'm not mistaken
also follows "threads".  Would someone who has used both like to comment?
Are nn and trn comparable in features?  Am I missing out on something
trn does that nn doesn't do?  


-----------------------------------------------------------------------
      Ed Braaten           |  "... Man looks at the outward appearance, 
Work: ed@de.intel.com      |  but the Lord looks at the heart."              
Home: ed@dah.de.intel.com  |                        1 Samuel 16:7b
-----------------------------------------------------------------------

xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (12/30/90)

ed@dah.de.intel.com writes:

> I also had a lot of trouble getting trn to run, and (between core
> dumps) I didn't really like the interface much. I don't understand all
> the fuss over trn. I find that nn is much more robust and if I'm not
> mistaken also follows "threads". Would someone who has used both like
> to comment? Are nn and trn comparable in features? Am I missing out on
> something trn does that nn doesn't do?

Well, I've used nn a little; I found it too big a stretch from rn; at
the time they maintianed incompatible .newsrc files, though that's been
fixed, but the big problem I found was a fairly opaque user interface,
and a nasty habit of getting direct and inverse video backwards as often
as not.

Lots of people swear by nn, which _does_ follow threads, but its big
claim to fame is preprocessing kill file commands, so you never see the
articles at all.

I don't like, or use, kill files. The trn article selection interface is
very much like the rn "=" command interface (but with the ability to
select stuff as you go along, rather than after you've left the "="
listing), cleaned up and sorted by threads, and with the ability to mark
stuff to read or discard by whole threads at a time with a single
keystroke. That makes it worth my time to go through even multiple
hundred current unread article newsgroups and nuke the threads I want to
miss, which really doesn't take two minutes at 1200 baud, and leaves me
in complete control of what I read or don't and usually with half the
articles discarded quickly.

Example: some threads I would kill, but some authors I'd read even in
those killed threads. With trn, I can see who wrote what in the threads,
nuke the whole thread if no one interesting is contributing, or read it
and threadwalk quickly to the author I want if s/he's there.

For the experienced rn user who is not a kill file fan, trn is a much
easier move.

It does have a few bugs, but not important to its operation. It often
displays wildly inaccurate counts of articles left to read, it is a lot
of fun to see that I am seeing a windwo of articles 167% of the way
through the total display, and it walks the threads in order, but
between threads out of arrival time order (backwards, I've been told).
Perhaps as a result, it can give you an "end of newsgroup foo.bar"
message while several threads remain to be read, but it tells you that,
too.

As I said, these bugs are harmless, and the gain in newsgroup reading
efficiency is wonderful. I'm making it twice as far through my active
list in my .newsrc, these days, and I still retain complete control over
what I read, without kill file overenthusiasm.

Kent, the man from xanth.
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>

pjg@acsu.buffalo.edu (Paul Graham) (01/06/91)

ed@dah.de.intel.com writes:
|I don't understand all the fuss
|over trn.  I find that nn is much more robust and if I'm not mistaken
|also follows "threads".  Would someone who has used both like to comment?
|Are nn and trn comparable in features?  Am I missing out on something
|trn does that nn doesn't do?  

i used rn for years then gave it up for gnews.  i still miss gnews but . . .
i switched to nn when the .newsrc was fixed.  it's great, *real* fast
and it has a number of convenience features i really like.

however i now read news with trn because i like to follow threads in
reply order.  nn groups by subjects and sorts by date.  trn uses the
references line (and falls back to the subject line sorted by date) so
you can slip right along in *order*.

if trn were as fast as nn and could follow threads across groups i'd
stop missing gnews.  or if thread following is added to nn i'll move
right back.

i still use nn to read digested groups and certain other ones.

-- 
pjg@acsu.buffalo.edu / rutgers!ub!pjg / pjg@ubvms (Bitnet)
opinions found above are mine unless marked otherwise.