pcl (05/31/82)
We are running the latest readnews release and I am bothered by a minor bug. It was designed so that if an article was larger than the screen, readnews would just display enough to fill the screen and than ask if you wanted more displayed. This is great. It means I don't have to keep my hands on control-s/control-q all the time. But now the bug. If the article is less than screen size, but together with the header for the next article, it is larger than screen size, readnews displays the whole article and then the next header; thus scrolling the top of the article off of the screen. Since I don't have my hands on control-s I'm not ready for this and I loss part of the article. This is an easy fix I'm sure. Can those who write readnews consider it.
salkind (06/02/82)
The readnews bug (where the top of the article flys off the screen) indeed has an easy fix. Just change the 18's to a 15's in readr.c. This catches most cases (articles with lines >80 chars still sometimes lose). I would also like to see this change in the next official release of B news. Have a good day... Lou Salkind cmcl2!salkind
pavel (06/03/82)
Actually, just changing the 18 to a 15 to stop the text of certain messages from going off the top of the screen is insufficient. This fix makes the assumption that all terminals have 24 lines, surely false. Currently the Ann Arbor Ambassador exists with between 18 and 60 lines and the BBN BitGraph has 64 lines. Surely this trend will continue. Therefore, I would prefer to see either of the following two solutions: 1) Find out from termcap (or the new terminfo system) how many lines the terminal in fact has OR 2) After sending something through 'more', have readnews print out a '--Done--' prompt and wait before going on to the next article. Personally I prefer the first solution, but only if one can get the number right \\every// time, not just for articles under 80 lines... Pavel Curtis
martin (06/03/82)
the subject of 15 or 18 or whatever number of lines can be got around
by using term{cap,info}. i would like to see the PAGER function build
into readnews, using screen size found from $TERM. if the user wants
to use his own PAGER, then fine, but he must also supply a page length
to readnews. it seems silly to bring only half of the termcap logic
into readnews and still not put a mini 'more' in there also.
martin levy. BTL Holmdel
lime!martinmark (06/04/82)
All this talk about changing the cutoff from 18 to 15 is amusing, but has nothing to do with the problem. There is no easy solution to the problem. Suppose, for example, that the message has 17 lines, that there will be 10 lines printed by the header of the next newsgroup, and that the cutoff has been set at 15. readnews decides the message is long enough to go through more, and more prints the message, stopping every 23 lines. Obviously it will reach the end of the message without stopping, at which point it will exit, and readnews will go on to the next message, print those 10 header lines, and the top of the message runs off the top of the screen. There are three solutions I see. Others are welcome. (1) Pause asking for more input (like the qfr prompt at the end) after every article. This would probably be very painful for the user. (2) Build a pager into readnews. Since to do this really well requires readnews to know as much about your terminal as more, this seems like a bad idea unless it's a very simple pager that doesn't try to erase the prompt. (3) Put page mode in your tty driver. (This is what I do.) This stops the screen when 23 lines go by without you typing anything, no matter what program generated it. Mark
salkind (06/04/82)
I believe the cutoff does matter, because if you use the default pager, the news program adds some extra newlines to bring the total number of lines to 23. Correct? I suggested the change from 18 to 15 not as a solution to the problem, but rather as a quick fix (be nice...). There are no doubt many better (and more time consuming) solutions. Lou
tihor (06/05/82)
Actually the general solution would seem to be to set the pager cutin size to be screen size - next article header size - 1, tell the pager to pause every screen size - 1 lines, and to pipe the next article header into the pager right after the end of the previous article. Granted this would fail to fully use one line of you screen in mid article so as to insure that the More? [ynq] prompt allways fit on the screen but it really seems like a small price to pay. Further if it is too dificult to tell the Pager things about screen size from readnews one could allways require that the user define PAGER to be the local pager of choice with an appropriate option set to use this facility. Am I missing some other, obvious problem with this solution?
ajlill (06/07/82)
A quick and dirty fix to the problem (untill someone changes readnews) is to unclude in your .cshrc the line setenv MORE '-nn' where nn is 8 less then the number of lines on your terminal (since there are 8 lines in the header when readnews enters a new group). This may mean you hit the space bar more often when readin long files but it is better than loosing part of an article. Especially when it's the last in the group and there is no nice way to go back to it. Tony Lill decvax!ajlill
lepreau (06/07/82)
The '-' command works perfectly well across newsgroups (in B news 2.3+ anyway). jay lepreau
ladm@kitc.UUCP (John Burgess - Local tools ADM) (07/24/85)
A local user has reported to me that
readnews -t string
will not find "string" when it is the LAST word in the title.
Looking for "strin", works.
It appears that the problem is something to do with matching the
end of the title.
This is in 2.10.2. Has this been reported/fixed before?
If so, please send fix. If not, I'll look into it ... someday.
--
John Burgess - Local Tools Administrator
ATT-IS Labs, So. Plainfield NJ (HP 1C-221)
{most Action Central sites}!kitc!ladm
(201) 561-7100 x2481 (8-259-2481)mlr0@bunny.UUCP (Martin Resnick) (01/26/86)
Problem with readnews: Last message of a newsgroup is n*22-k lines where k is <= 10. More displays 22 lines per screenful. After displaying the last 22-k lines of the message, the name of the next group is displayed followed by the header of the first message of the next group (about 10 lines worth). Of course some of the text of the previous message has now scrolled off the screen! Does rn have this same problem? Is there a fix for this? Thanks.