Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site umcp-cs.UUCP
Path: utzoo!linus!philabs!seismo!rlgvax!cvl!umcp-cs!israel
From: israel@umcp-cs.UUCP
Newsgroups: net.news
Subject: Re: wishlist
Message-ID: <2865@umcp-cs.UUCP>
Date: Fri, 30-Sep-83 21:09:54 EDT
Article-I.D.: umcp-cs.2865
Posted: Fri Sep 30 21:09:54 1983
Date-Received: Sun, 2-Oct-83 14:32:06 EDT
References: <2353@utcsrgv.UUCP>
Organization: Univ. of Maryland, Computer Science Dept.
Lines: 73

While we are discussing wishlists, here are my wishs for changes to
the "readnews" msgs interface.

I'll start off with the easy ones.

a) When you start reading news, readnews gives a default newsgroup
   subscription list of "general, all.general, net.announce" and
   those are the only newsgroups in your .newsrc.  When you read
   another newsgroup, it will be added to your .newsrc, but
   calling "readnews" with no arguments still gets you the default
   list (i.e. does not get you the new newsgroup).  To get it,
   you either have to put an options line in your .newsrc with each
   new newsgroup explicitly on it, or you have to set "options -n
   all" (or something similar).  I feel that readnews with no
   parameters (and no options line) should default to every newsgroup
   you currently subscribe to.  This way, everytime you want to read
   a new newsgroup, "readnews -n <group>", and from then on you'll
   get it.

b) When you unsubscribe from a newsgroup, the only way to start
   reading it again is by editing your .newsrc to change the "!" into
   a ":".  Even calling it explicitly with "readnews -n <group>"
   or saying "readnews -x -n <group>" (read <group> and ignore the
   .newsrc file) will not work.  readnews should re-subscribe you
   to a newsgroup if you asked for that group explicitly, and the
   -x option should totally ignore your .newsrc.

These two suggestions are because I feel that when using a program
like readnews, you should not need to know any other programs at
all (such as editors and the like).  You shouldn't have to know how
to use the editor just to read more than the default groups, or to
start re-reading an old group you un-subscribed to.

And on the the more difficult changes ...

c) /usr/lib/news/active should have the first valid message number as
   well as the last number.  This will tremendously speed up new users,
   as well as "readnews -x"'s and re-subscribing to old groups.

d) Readnews would be a lot easier to use if it prompted for commands
   in cbreak mode (either as the default, or as an option).  For
   example, 'n' would act like 'n<CR>' does now.  I wrote a bulletin
   board system that worked that way, and it was so much nicer to use.
   (Not only my opinion, most (or all) of our local users felt the
   same way)  This isn't a trivial change; there is a lot of stuff to
   be done, especially with the multiple character commands (like 's'
   and <digits>).  (If someone is going to implement this, I can send
   you my code as a good launching point for those changes).

e) How about a command 'S <number>' which would skip to that number
   like <number> does, but would mark all the ones in-between as
   read?  Maybe it should just be 'S' and work like 'N'.  I've had
   two users in the last two days ask me how to mark the entire rest
   of a newsgroup as "read" from within readnews, and all I could tell
   them was "readnews -n <group> >/dev/null &".

Also, someone here ran checknews, and it and readnews disagreed on
whether there were new messages.  It turned out that his home directory
from /etc/passwd was one place and his environment home directory was
another, and "checknews" seems to use the environment while "readnews"
was using the /etc/passwd entry.  Shouldn't these two programs use
the same .newsrc (Personally, I feel that they should both use the
environment variable; I think that gives the user more power, though
it's a rare case when they disagree.)

Anyway, the first two suggestions could be just differences of
opinion on the way certain cases should be handled, so if someone
(preferably one of the authors) has reasonable rationales for why
these should be handled the way they are rather than the way I've
suggested that they act, I would love to hear them.

~~~ Bruce ~~~
Usenet: seismo!umcp-cs!israel   Arpanet: israel.umcp-cs@Udel-Relay