[ On Wednesday, March 29, 2000 at 14:55:15 (+0100), Roger Brooks wrote: ]
> Subject: Re: Anyone recommend a good terminal type?
>
> But many vt220 emulators do have colour support (and I suspect real
> VT220 terminals are a bit rare these days).

Perhaps there should be a generic "vt220 plus colour" terminal type
definition, but regardless there must be a plain "vt220" terminal type
that does not claim the terminal supports colour.

>  And a properly-constructed
> ANSI escape sequence parser should silently ignore any SGR parameters
> which it doesn't understand.  Certainly a Wyse-185, which is the nearest
> we have to a hardware VT220 does.

Indeed, but that's not the point.  A "termcap" (or "terminfo") entry
defines the capabilities of the terminal.  If it claims colour is
available and the application tries to use colour instead of something
more useful under the circumstances, like bold, dim, and underline,
etc. then the user will not be happy.  Personally I'd be more than just
unhappy -- I'd be very angry and be cursing six ways to Sunday until I
managed to edit the offending crap out of the broken terminal
definition.

As for the authors of the terminal emulators (and in particular the
eumlators used for the OS consoles of machines like PCs), they should be
extremely careful in thinking about which base terminal type to choose
to emulate, which features to leave out (if any), and just as
importantly which new features they might think to add to enhance the
base terminal type (if any).

Personally I'd be extremely happy if the standard MI console emulator
for NetBSD were to take a lesson from Kermit and *exactly* emulate a
real terminal with no extensions at all whatsoever, with 100% bug-for-
bug compatability.  If that's a vt420, or just a vt220, or even just a
vt100, that would be just fine by me.  If several types are possible
then all the better, just so long as they are *perfect* emulations.  Of
course that does mean being able to go into "setup" mode to tweak the
terminal's behaviour (at least for those parts that affect the screen
and keyboard, etc.), just like with a real terminal.  There's nothing
more painful and frustrating than a unique terminal "emulation" on a
console that doesn't 100% match any real terminal from a
terminfo/termcap point of view, especially when what's really there is
so vaguely documented that it takes a weeks worth of experimentation and
fiddling to write a proper terminfo/termcap entry (not as much of a
problem of course when you have the source).  Do it right, or don't do
it at all.

As for the issue of having a proper terminal type on a remote system
that I might access from a console emulator, well at least with DEC's
original terminals I have some assurance that using a "lesser" termcap
definition for an older real terminal on a more capable terminal will
still work OK so long as the termcap I choose doesn't depend on some bug
in the original terminal that's been fixed in the newer and more
advanced one.

These days though I can usually depend on being able to run an xterm
somewhere and almost 99% of the time the xterm terminal definition on
the target host is close enough within spec that at least highlighting
works properly and emacs/vi function without the need for too many
screen refreshes.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>