From: CSBVAX::CSBVAX::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 23-NOV-1988 08:13 To: MRGATE::"ARISIA::EVERHART" Subj: Re: Problems with V5.4 ANU NEWS Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Wed, 23 NOV 88 04:15:35 PDT Received: from ucbvax.Berkeley.EDU by KL.SRI.COM with TCP; Wed, 23 Nov 88 03:51:41 PST Received: by ucbvax.Berkeley.EDU (5.59/1.31) id AA13207; Wed, 23 Nov 88 01:40:53 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-vax@kl.sri.com (info-vax@kl.sri.com) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Nov 88 09:11:59 GMT From: munnari!otc!metro!basser!usage!ccadfa!anucsd!csc3!csc!gih900@uunet.uu.net (Geoff Huston) Organization: VMS NEWS V5.2 Subject: Re: Problems with V5.4 ANU NEWS Message-Id: <1031@csc.anu.oz> References: <231@arnold.UUCP>, <974@csc.anu.oz>, <1440@kuhub.cc.ukans.edu> Sender: info-vax-request@kl.sri.com To: info-vax@kl.sri.com In article <1440@kuhub.cc.ukans.edu>, sloane@kuhub.cc.ukans.edu (Bob Sloane) writes: > While we are on the subject, I have a list of 17 problems with NEWS (appended > below). Could you tell us which if any of these are fixed? Yep - this may take a few pages - skip this item NOW unless you've running a copy of NEWS :-) Geoff Huston > > Known Problems in NEWS Version 5.4 (16-Nov-1988): > ------------------------------------------------ > > 1. When ADD'ing a batch file directly from VMS MAIL (EXTRACT/ALL/HEAD), > NEWS creates a spurious "null item" between *each* item in the mail file. > These "null items" are posted to the default newsgroup (junk). The items > come from "** Sender Unknown **" with path "our_node!Path-Lost". All valid > items in the mail file are ADD'ed _almost_ correctly: their paths are all > "our_node!Path-Lost" (where "our_node" is our local NEWS node). The items > in the mail file are 'N'-prepended. Extracted sample "null item" follows: Fixed in V5.6 > 2. When ADD'ing a NEWS batch file in non-'N'-prepended "#! rnews" format, > NEWS adds a spurious "null item" before adding the first item (only). > The first line of the batch file is "#! rnews nnnn". If the first line > is blank, the spurious item is not added. All valid items are added > correctly. Fixed in V5.6 with 1 minor exception case, which will be fixed in the next release. > 3. When deleting a newsgroup, NEWS leaves the directory for that deleted > newsgroup in the news_root: directory tree. With a significant number > of newsgroup deletions, a corresponding number of directories are left > "dangling". Can NEWS delete the "dead wood" of directory trees > (including "upper branches" where applicable) when deleting newsgroups? Yes - V5.6 SKIM command also skims off all empty directories. > 4. When using the "scroll" feature of READ, the following problems occur: > (a) For a multi-screen message, pressing (and occassionally > ) at the first page (i.e. Top of Display) often takes > the display immediately to the last page (i.e. End of Display). Fixed partially in V5.6, more fixes in the next version for /NOSCREEN mode problems > (b) Using up- or down-arrow, or typing "up" or "down" often causes the > screen to be fully ("ripple") updated rather than up- or down-scrolled > as appropriate. (VT220) Correct - I've been mucking around on which update type is faster! > (c) Typing "u" (instead of "up") causes an "ambiguous verb" CLI error > (correctly), but returns to the item directory at the current item, > instead of remaining in the item text. Fixed > (d) Typing "dow" (or "do") does not give an error, nor does it move through > the item text. It returns to the item directory at the _next_ item > (if it exists). Fixed > (e) Removal of the blank separator lines at top and bottom of the display > has made the screen appear very cluttered and harder to read. True, but the header and trailer lines are displayed in bolded text - the trade off is more information per screen! > (f) The full screen update for the last page of an item makes finding one's > place in the previously read text difficult. Up-scrolling for this > last page would be far preferable. (Similarly on reversing to Top?) Fixed in V5.6 > 5. The following are suggestions for the READ with scroll feature: > (a) The old style of reading should be retained as well as providing the > new (very useful) scrolling feature. Scrolling should be enabled with > a (yes, yet another one) qualifier such as /[NO]SCROLL (on by default > perhaps?). I'm not sure if I'm going to persue this suggestion > (b) If scrolling is enabled, a simple mechanism for going to the top or > bottom of the item should be provided. Perhaps the commands TOP and > BOTTOM could be implemented in a similar context-dependent fashion to > UP and DOWN, operating on directories as well as item text. Fixed V5.6 with TOP and BOTTOM commands > (c) Bring back the blank separator lines (see item 4(e) above). same answer as 4(e) !!! > 6. In explicit NOSCREEN mode, SELECT a newsgroup, do a DIRECTORY and then > type to READ the article pointed to. The following problems occur: > (a) The _next_ item is displayed rather than the item pointed to. > (b) Paging does not work. (Reported for NEWS v5.3). > (c) The header lines are missing or incorrectly displayed. Fixed in a release following V5.6 - this bug took some time in finding !! > 7. Thanks for the broadcast trapping. However, some suggestions: > (a) The messages should be put into a buffer (virtual display) which can be > viewed (with scrolling capacity) with a command such as SHOW MESSAGES > (SHOW BROADCASTS ?). Obviously, if there are no broadcasts, simply > issue such a message. > (b) It is difficult to know just how to immediately display these > broadcasts. The current method of overwriting the prompt and message > (status) line has its shortcomings. (Lose prompt and message; > cursor left some distance into broadcast message). Hmmm? I have > no simple answer, sorry. Unfortunately neither do I at this point - I'm still working on a suitable mechanism!! > 8. Will GMT ever equal GMT or should it be "EST" or "(Local Time)" or ?? NEWS_TIMEZONE is introduced as a logical name in V5.6/ This should be defined as your local timezone. > 9. Items can be left displayed as unread in the item and newsgroup directories > when in fact all items in the group have been read. READ/NEW (if the > "unread" item is in a registered newsgroup) does not find the item. I think this one is fixed, but it has been a hard one for me to reproduce!! > 10. When loading the subject of a REPLY, the full subject line in the item > should be used. Agreed, and fixed!! > 11. Extract from newsgroup comp.os.vms: > > From: sys_ms@bmc1.bmc.uu.se > Date: 24 Aug 88 20:48:00 GMT > Newsgroups: comp.os.vms > Subject: Bug in VMS News 5.4 > Message-ID: <3789@bmc1.bmc.uu.se> > Path: ucsvc!murdu!munnari!uunet!mcvax!enea!kth!draken!bmc1!sys_ms > Organization: Biomedical Center, University of Uppsala, Sweden > > It is still there. There is a bug in VMS News 5.4. > If you post an item into an empty newsgroup the > item is not accessible for reading. The following > postings will be readable. Fixed in V5.6 > 12. All NEWS system files should be more truly free-format, and conform to the > following requirements: > - no specific column positions necessary; > - any white noise (*tabs* and/or spaces) can be used as field separators. > This applies to the files MAILPATHS., NEWS_ADDRESS.CNF, NEWS.SYS, > NEWS.DISTRIBUTION etc.. (NEWS_ADDRESS.CNF cannot contain _only_ tabs.) Fixed in V5.6 > 13. When a syntax error occurs while reading a message, the user is left in > the directory display, rather than in the message text. This is a rather insidious side-effect of the structure of the code at this point - sorry to say its NOT fixed so far!! > 14. After an EXTRACT command while reading a message, the user is left in > the directory display, rather than in the message text. as with 13. > 15. READ in /NOSCREEN mode doesn't display the From: or Subject: lines in > the first screen of data, but does in subsequent screens. Fixed. > 16. DIR/ALL or DIR/NEW or DIR/REG do not work in /NOSCREEN mode. Fixed. > 17. After using READ/EDIT (and other commands) the definitions of many of the > keys is lost. For example, the up-arrow key on a vt100 is no longer the > UP command. It recalls commands. This is a side-effect of introducing broadcast trapping - It appears that a SMG$ENABLE_BROADCAST call also as an unwanted side-effect enables line edit mode, disabling program control of the arrow keys - This has been worked around- but I maintain that the original bug is that of SMG (1 of many that still plague the edges of SMG!) -- Geoff Huston Computer Services, Australian National University gih900@csc.anu.oz