VT100 and bagbiting

[gwyn at BRL-VLD.ARPA]

From:      Doug Gwyn (VLD/VMB) <gwyn at BRL-VLD.ARPA>

Yes, the ESC key should be removed from ANSI X3.64-conforming terminals.
The reason is that ESC indicates the start of an escape sequence and so
it cannot have meaning by itself.  What some people have done for things
like screen editors to support user-typed ESCs is to see if the input
queue is still empty a second or so after getting an ESC, and if so
assuming that it could not have been the start of an escape sequence.
I once modified a screen editor so that ESC ESC was taken as a user-
typed ESC, and ESC-anything-else was assumed to be an escape sequence.
All these kludges are caused by having an accessible ESC key.

As to DC3/DC1, the old Teletypes did use them for controlling the
attached paper tape units (DC1 = enable reader, DC2 = enable punch,
DC3 = disable reader, DC4 = disable punch as I recall), but their
meaning is just "device control".  It is fairly easy to see how the
DC3/DC1 flow control protocol logically evolved from this.  As far as
I know this in-band flow control protocol is not an ANSI standard, but
it definitely is one of three industry standard asynch flow control
protocols:
	DTR/CTS per-character handshaking (lousy over modems with most
	computer systems)

	ENQ/ACK master-slave handshaking (not suitable for real full-
	duplex interaction as we know it)

	DC3/DC1 (XOFF/XON) flow control (in both directions)
My impression is that the vast majority of ASCII terminals being sold
today provide DC3/DC1 flow control, usually as an option (often the
DTR/CTS method is available as an alternative).  This implies that
it is a mistake for a programmer to expect a ^Q or ^S (DC1 or DC3)
to be typed by the user.  Indeed, years ago DEC published an internal
standard that prohibited the use of ESC ^S ^Q (and maybe ^R ^T) as
user-typed input for DEC program products.  (I do not know how well
this corporate standard was obeyed.)

As a recent example, the Teletype model 5620 (reborn Blit) in its
resident terminal mode does not transmit ^S or ^Q when they are
typed on the keyboard, but it does transmit them automatically when
its input buffer is nearly full and when the user puts it in SET-UP
mode (i.e. DC3 is sent to suspend host transmission then DC1 is sent
when the emergency is past).  One could argue that user ^S ^Q should
be coordinated with automatic DC3 DC1 (as on the DEC VT100), but
(a) the resident terminal mode is not used for real 5620 work, and
(b) the function keys can be programmed to send ^S and ^Q if desired.

One of the great lossages on 4.2BSD is that DC3/DC1 flow control is
not available in "RAW" mode, although the need for this support is
actually dependent on the terminal hardware, not on whether or not an
application program wants input canonicalization done.  This non-
orthogonality of the various things bundled into the meaning of "RAW"
mode was fixed in the terminal driver supplied as part of UNIX System
III and V.  This may explain why AT&T UNIX users understand the use
of DC3/DC1 flow control and BSD users think that its existence is a
terminal design botch..