improving terminal response

[utzoo!decvax!ucbvax!mhtsa!ihnss!cbosg!cbosgd!mark]

Here's why the suid front end approach is "messy".  All I have to do
is run edit, then do
	!csh
and I have myself a niced shell!  Clearly if you use nicing you have
to have the program disable it for subshells and the like, so you
have to have the program know about it itself.  Which is why you don'
t want to do it.

It makes far more sense to modify the scheduler to recognize certain
kinds of behavior and treat them specially.  Berkeley UNIX already
does this, and response inside vi is excellent.

Here's another little known property of screen editor response.  I often
hear somebody say "response in vi is awful, so I usually use ed".  This
person almost always brought up vi in his own directory and tried it for
a while.  He multiplied the poor response by the number of users logged in
and figured it would load down the system a bunch for everybody to run vi.
But what he didn't realize is that since vi is shared text, the more people
who run it, the better response will be because it is always swapped in.
This benefits people running, say, edit and ex also, since they are links
to the same file.  Another truism is that more memory helps a bunch.
Running vi on an 11/45 is usually a disaster because you only have 256K.
You should have at least 1/2 meg and preferably 1 meg to get good response.

This is true of any large screen editor, not just vi.  Of course, if you
have half your users running vi, half running EMACS, and half running
the Rand Editor (leaving the other half sitting in the shell or doing
other things... yes, it's true you always have twice as many users as
you have) then these big programs fight each other for memory and
response goes down the tube.

	Mark