Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: nyu notesfiles V1.1 4/1/84; site ur-univax.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!rochester!ur-univax!jpk
From: jpk@ur-univax.UUCP
Newsgroups: net.arch
Subject: Re: dumber terminal device drivers // DG
Message-ID: <24800001@ur-univax.UUCP>
Date: Mon, 13-May-85 11:34:00 EDT
Article-I.D.: ur-univa.24800001
Posted: Mon May 13 11:34:00 1985
Date-Received: Thu, 16-May-85 02:45:07 EDT
References: <2135@sun.UUCP>
Organization: University of Rochester: Computing Center
Lines: 24
Nf-ID: #R:sun:-213500:ur-univax:24800001:000:1349
Nf-From: ur-univax!jpk    May 13 11:34:00 1985


Regarding the "right" way to design a terminal interface:  All
that has been cited in favor of DG terminal interfaces as far
as user friendlyness (command line editing etc) could also be
said of VMS, starting with version 4.0, and of course assuming
you buy only DEC or DEC-compatible terminals.  But the applications
programmer has to become something of a systems hacker to make
use of anything other than default input mode.  What I'd like
to see is something that could be called both user- and programmer-
friendly.  Simply, consistent calls to the terminal i/o facilities
that can assume or inhibit any aspect of screen behavior.

Incidentally, typeahead echoing is a behavior that DEC never could
decide about.  Echoing was immediate on TOPS-10, immediate, delayed,
or ignored on RSX, depending on reads queued to the terminal, and
delayed until read by the application program (whether user software
or the command line reader) on RT-11 and VMS.  On TOPS-20, however,
you could choose either immediate or delayed mode.  Since that is
the only environment where I could experiment, I did so, and decided
that I like my reads echoed only when the program gets them.  It
fixes reads with no echo like passwords, and produces predictable,
consistent screen displays.  Anything which maniplulates the screen
needs it anyhow.
					-- Jon Krueger