Call for Opionings (Virtual Terminal)

[Ray Chen]

>In the context of this, let us consider improvements to the TermCap system.
>One real inadequacy of TermCap is its less than adequate support for *INPUT*
>translation.  The Unix editors and such finesse the issue by refusing to
>support terminal capabilities such as arrow keys, built-in insert/delete modes,
>and other features.

Untrue.  termcap supports these features quite nicely by doing what a
database should do, indicate the presence of the features (see ku, kd, kl, kr,
im, etc.).  What the program decides to do with this information is another
story.

>From a "User Friendlyness" point of view this is a real
>loss, although a cogent argument can be made for the current scheme of
>providing a terminal-independant input language (I,J,K,L, etc in VI, etc).
>Other issues, such as "what happens when you type backspace in column one?"
>and "what happens when you type linefeed in row 24?" are finessed by using
>smart echoing to avoid the need to know.

So what's the matter with smart echoing?  On an IBM 327x terminal you end
up wrapped around to column 79 of the next||previous line.

>Long before finding out about TermCap I wrote a screen editor for really
>dumb systems, using a dedicated procedure for each terminal to translate both
>input and output to a program-specific internal language.  It will work on
>systems that do not provide raw, or even rare terminal access.  Right now it
>works on both Univac 1100 (Exec 8) and IBM 4341 (VM/CMS) systems.  To make
>the scheme work from a TermCap system one would need input translations.

Sigh.  First thing, you want to avoid having code for each terminal.
How many terminal types/classes does your editor support?  How much
code is there?  You want to write a single terminal driver, and load
the proper terminal codes into the driver at run-time.  termcap allows
you to do this by giving you common names for the codes and allowing
you to read the codes for the terminal type in on program
initialization.

Second, the reason why vi and other programs like to operate in raw mode
is that they like having access to every single character.  This lets
you execute commands with one keystroke even if the keystroke doesn't
send an interrupt to the computer (or a return) to get its attention,
which is essentially what function keys on say, 327x terminals do.
vi could run in cooked mode and ask the user to hit a <return> after
every single-letter command but that would get to be a real pain.

Actually, we'll probably end up moving towards having dumb computers
and very smart terminals in the future.  This will make editing much
faster since it will minimize the load on the computer and the i/o over
the line but for most of us, that will have to wait until cycles get
a little cheaper.  Companies that are "ahead of their time" regarding
this situation got into them because their computers were so dumb they
didn't have a choice.  How much does a 327x terminal cost?

> There also exists a "TN3270" program that does TelNet into IBM systems from
> Vaxen.  Unfortunately, TermCap does not provide enough for doing this, so the
> program has its own database of terminal types.  An expanded TermCap system
> could obviate the need for Yet Another Terminal Database....

Sorry, you're many years too late.  Ever heard of terminfo?

	Ray Chen
	princeton!tilt!chenr