avi@pegasus.UUCP (01/31/84)
I am getting tired of this discussion. Many reasonable terminals already have the ability to buffer your output. My concept-108 is available with 8 pages of memory and my HP has options for ten pages. When something floats past your screen "window", a few flicks of function keys will get things back into view. Or, you can use other terminals that have huge screens -- such as my BLIT with 72 lines by 87 characters. Why should you depend on your software to buffer every "small" stream of output. An alternative solution is to log an entire session. Just for the fun of it, I used to run my HP-2625 (a personal computer) in a mode that recorded my entire session on a floppy disk. This allowed me to back up indefinitely. It did get annoying when the output paused while yet another page was written to the floppy. Yet another method (for non-interactive programs) is to do things from within the shell macro in Goslings emacs. You then have an absolutely powerful pager (the editor) constantly available in a multiple window environment. This offers you tremendous advantages over "more" and related programs. You may want to modify the MacLisp code so that it keeps more than the last 10000 characters in the buffer. In the BLIT layers environment, I download terminal emulators (for things like hp and tektronix). Some of these emulators provide paging within the terminal under the control of a mouse driven pop-up menu. Some of the emulators will pause after a screenful (no matter what the size/shape of the current window!) and flip the screen into reverse video -- until you hit any key. Obviously, this is not an average terminal. The moral of this article is: Don't put everything in the kernel! There are many other ways that work reasonably well. Many of them don't even involve any additional CPU cycles on the host. -- -=> Avi E. Gross @ AT&T Information Systems Laboratories (201) 576-6241 suggested paths: [ihnp4, allegra, cbosg, utcsstat, hogpc, ...]!pegasus!avi