pn (12/11/82)
I've been living with a scrolling problem in news for months now and thought I'd ask if there was some easy fix or if anyone was even working on the problem, or if I'm just doing something wrong. An 18 line article which is the last one in its group will be hard to read, because the first few lines get pushed off the top of the screen. Comments? phil ngai ucbvax!amd70!phil decvax!decwrl!amd70!phil
george (12/20/82)
References: amd70.363 Readnews normally only invokes a paginator (like "more") if the article is greater than 18 lines. A screen is normally 24 lines. This leaves 6 lines for header and prompt of next article. This is not always sufficient. The first article of a newsgroup will have the newsgroup name included in the header display. The easiest thing to do is put "-h" in the options line of your ".newsrc" file. This produces abbreviated headers. This will not fix the problem. It will probably make the occurrence of the problem rarer. A better thing to do is fix "readnews". Change some line in "readr.c" from ``if (linecnt(fp) > 18 && *PAGER)'', to ``if (*PAGER)''. Maybe you should also change the version number and date in this file. Set and export the environment parameter "PAGER". If you use the Bourne shell, "sh", and have the "more" program, adding a line like ``PAGER="exec more" ; export PAGER'' to the file ".profile" in your home directory should work. A related problem is the loss of lines on the last frame when the "more" program is invoked. I believe this happens because "more" normally exits upon writing the last frame of a file rather than waiting for user input. Readnews then prints the next header and prompt, potentially scrolling some of the last frame out of sight. I do not know if there is an option to the "more" program to inhibit this. I use my own paginator, which does not behave in this manner. George Rosenberg
gnu (12/21/82)
One aid in solving the readnews scrolling problems would be for readnews to look at the environment TERM and TERMCAP variables to see how big your screen really is. Our screens are 34 lines but we get the delay of "more" even when we don't need it, like on 24 line messages. And people on smaller screens (using a micro as a terminal, perhaps) lose worse. A second thing would be for readnews to stay "one message ahead" of the user; before deciding how to paginate message X, figure out how big the header of message X+1 is. It could furthermore pipe the header of the next message into the current message's pager, so it wouldn't mess up the last page before you're done reading. I think the ultimate solution is to build the paging and the readnews into the same program. Pipes and such are great for non-interactive stuff but they don't seem to work very well for dealing consistently with a user. John Gilmore, Sun Microsystems
mark (12/21/82)
The real solution to this problem is to have page mode in the tty driver. We have it here and it solves the problem completely and efficiently (no long delays to start up more). We set our default pager to "" (no paging) and let page mode handle it. Page mode was originally done at CCA and a working copy is at Berkeley - hopefully it will be in 4.2BSD.