phipps@fortune.UUCP (Clay Phipps) (02/02/84)
I must disagree with Chuqui on the automatic paging issue.
I upload and download files by doing a "cat" on the UNIX side
to create a stream a data that the communication software on my PC
reads or writes.
Nonetheless, this file transfer via "cat" is much less frequent
than the occasions when I curse UNIX for requiring me to guess in advance
whether or not a file contains or a command will produce
more than a screenful of data. Having to watch the screen so I will be ready
to leap for the CTRL-S key combination to suspend output is not acceptable
(I usually have other productive things to do while I wait for output
such as from Rob's time-consuming "find"). As Laura has already pointed out,
computers are much better at detecting a filled screen than people are.
I don't want to have to type commands twice just to be able to keep
the line of interest on the screen, but it happens continually.
The computer should exist to serve the human, not the reverse.
I am convinced that proper presentation of data on a terminal screen,
including automatic paging, is a wholly reasonable task
for the terminal driver. This is to compensate for the transient nature
of output to CRTs, which is one of their fundamental characteristics.
I would be quite happy to type commands before and after my "cat"
to disable then enable automatic paging (obviously, I could put
the command sequence into a shell script) if I got automatic paging
in return. I think that it would be a great trade.
This follows the general principle that the exceptional case,
rather than the common case, requires the extra effort from a user.
-- Clay Phipps
--
{allegra,amd70,cbosgd,dsd,floyd,harpo,hpda,ihnp4,
megatest,nsc,oliveb,sri-unix,twg,varian,VisiA,wdl1}
!fortune!phippska@hou3c.UUCP (Kenneth Almquist) (02/02/84)
If we are going to have a discussion of the value of pagers people should say a little about their hardware environment. First, it makes a great deal of difference what speed your terminal is set to. At 1200 baud ^S/^Q work fine; at 9600 baud they are a lot harder to use. The number of lines of memory in your terminal also makes a big difference, since with a decent amount of memory you can just scroll backwards to look a something if it slips by. Personally, I usually run at 1200 baud and have never used a terminal with only 24 lines of memory. I practically never use a paging program (although I do use Emacs to look at files), and given my current hardware I don't even view typing a space at the bottom of every page acceptable, much less desireable. Kenneth Almquist P.S. I'm not sure I understand the bit about stuff running off the screen while you aren't watching it. You can type a ^S before any output appears, and then later type ^Q to see if output is available yet. Alternatively, you can always redirect stuff to a file. (I know you can't ^Z a program and continue it with its output redirected to a file; but the solution to that is probably to fix the job control stuff so you can.)
phipps@fortune.UUCP (Clay Phipps) (02/18/84)
Per Kenneth Almquist's request, in the hopes of swaying those
who see no justification for an "automatic paging" feature
in the terminal driver, I am supplying more information
about my specific situation.
My computing environment is as follows:
Fortune 32:16, multi-user-configured FOR:PRO 1.7 (~4.1 BSD),
Fortune console, approx. 53kbaud (yes, fifty-three thousand baud).
VAX 11/780, UNIX 4.1 BSD, Fortune FIS 1000 terminal, 9600 baud.
I have installed the "automatic paging" feature (mentioned by
Warnock | Norskog) on my 32:16. It's great.
Unlike the average computer user,
I use both the computers to which I have access,
simultaneously, on a daily basis.
The 32:16 is all mine; the VAX must be shared with many people.
This is a common environment for software development at Fortune.
I handle the varying demands on my attention
by timesharing myself between the 2 CRTs and 1 desktop.
Design work, coding, debugging, and reading technical papers
often require intensive thought.
Typically, one CRT has a high priority activity than the other.
This is not to say, however, that I am not interested
in reading every single line of text on the low-priority CRT;
it just means that I will wait until I am jolly well ready to look at it,
that is, until I come to a reasonable breaking point in the high priority task.
Therefore, my mental timesharing discipline
is based on polling, not on interrupts.
I cannot engage in intensive thought if I am having to watch (i.e., poll)
a >= 9600 baud lower mental priority screen out of the corner of my eye
so I can suddenly reach over to hit CTRL-S.
It is evident that use of automatic paging is heavily dependent
on one's working style.
People who do not poll as I poll, or who are interrupt driven,
or have a slow terminal, may not want their CRT to behave as I want mine to.
I originally suggested that "automatic paging" be optional; I still do.
Those who don't like it or don't need it can turn it off,
or if it is disabled by default, leave it off.
However, if the feature isn't there at all,
those who want it cannot turn it on and leave it on.
How this is most appropriately done (again, for the entire terminal session
until deliberately disabled) is a matter for the gurus among us.
My suggestion that paging is appropriately assigned to the terminal driver
(analogous to handling forms control codes in a printer driver)
still sounds reasonable to me. Whether device drivers for terminals
belong in the kernel is a largely independent question to my view,
although I certainly cannot claim UNIX guru status.
I hope this has clarified my situation and point of view.
-- Clay Phipps
--
{allegra,amd70,cbosgd,dsd,floyd,harpo,hpda,ihnp4,
megatest,nsc,oliveb,sri-unix,twg,varian,VisiA,wdl1}
!fortune!phippsgwyn%brl-vld@sri-unix.UUCP (02/23/84)
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld> I agree that whether terminal paging belongs in the driver has an analogue in the question whether forms control belongs in a line printer driver. However, I would say NO to both. It is the job of the device driver to SIMPLY and DIRECTLY control the resource, not to try to "help" me when I may not want or need to be helped. How many of us have been bitten by line printer drivers that performed automatic "detabbing" because they "knew" that we would need it, when we tried to output raster files to a dot printer/plotter?