dumber terminal device drivers

[Guy Harris]

This particular article is more in the lines of "net.unix"; I'm sending
the reply there as well, and redirecting further followups there.

> Also, I think vi would be nicer if it *didn't* insist on rewriting a
> line every time you insert a character before the end.  This is not
> normally a problem, but on slower dialup terminals it sucks.

Try "set slowopen"; it won't rewrite until the insert is done.  Or try
running on a terminal with character insert/delete.

> As for specifying a list of "activation characters", the current "new"
> tty driver has three activation characters which apparently signal the
> running process (intr, quit, brk) - somebody could try writing a prog-
> ram that maps these into \n, ESC, and \t, with the tty driver running
> in raw -cbreak mode.  It seems like this would give you what you are
> looking for - buffered text input with activation caused by a small set
> of control characters.  Of course, you'll be basically ignoring most of
> the normal process control signals, but vi does that anyway.
> 
> Can this actually be done?  Has anybody out there tried it?  Am I tal-
> king through my hat again?  And what about Naomi?

You're confusing "signal" with "signal".  "intr" and "quit" send a real
live UNIX signal to the process.  "brk" just terminates a line, like "\n"
does, in "-cbreak -raw" mode.  If the driver is running in "raw -cbreak" mode,
you do *NOT* get buffered text input.  "raw" is like "cbreak"; you get no
erase/kill processing and each character is handed to the program at the
time it's typed.

99% of the time you very definitely want to run in "cbreak" rather than "raw"
mode.  For one thing, you can get the normal process control signals (which
"vi" does *NOT* ignore; try typing your interrupt character while "vi" is
doing a long operation).  For another, XON/XOFF works, which is very
important if you're using a VT100 in smooth scroll mode - or using any
other terminal which isn't running at the nominal baud rate of the line.

Furthermore, if you mapped the "intr" and "quit" characters, the interrupt
they caused would flush all input that had been typed until that point,
rather than handing it to the program.

By the way, all three of those characters are in the orignal V7 terminal
driver; Berkeley didn't add any of them.  (They're also in the System III/
System V terminal driver, although with slightly different names.  The
VAX System V driver, at least, has two characters like the "brk" character -
c_cc[VEOL] and c_cc[VEOL2].  The latter isn't documented and may go away.
This still isn't enough.  Your scheme needs three.)

	Guy Harris
	sun!guy