[ On Monday, February 11, 2002 at 20:57:08 (+0100), Manuel Bouyer wrote: ]
> Subject: Re: default TERM type?
>
> On Mon, Feb 11, 2002 at 08:17:39PM +0100, Thomas Klausner wrote:
> > 
> > Why is the default terminal type for i386 in /etc/wscons.conf vt100
> > instead of wsvt25 (which seems to have been created especially for
> > wscons...)?
> > 
> > Any reason not to switch to wsvt25?
> 
> I guess because vt100 is known on most unix system, when wsvt25 is not ?

Indeed, but I think that completely misses the point.

You MUST always tell your applications the correct terminal type for the
type of terminal (or terminal emulation program) you are using, and
presumably someone must write a correct and complete description of that
terminal so your applications will use it correctly.  If you happen to
login to another system that doesn't understand that terminal properly
then you should probably either teach that remote system about that
terminal yourself (pretty trivial for any type of remote unix system),
or use an intermediate emulator like 'screen' that implements a type of
terminal the remote system already knows how to drive.

You don't use a "foo" terminal and then try to tell all the world it's a
"bar" terminal just because the rest of the world only knows about "bar"
terminals.  That's like looking for your keys under the light because
that's where the light is.  You're not going to find your keys unless
you move a light to where they actually are.  You're not going to have a
joyful experience using your "foo" terminal unless/until you teach the
rest of the world how to drive it.  Your only other choice it to throw
away your "foo" terminal and instead use a "bar" terminal.

Teaching remote unix systems how to drive a specific terminal is usually
very easy, particularly when we already have a good and portable
description of that terminal type.

While there is some room for supersets of functionality, generally
speaking they're pretty damn pointless unless you can use them, right?
You can't use the additional features unless you can teach the systems
and applications you use about them.  Of course you're really careful,
and you understand exactly what you're doing, then you can declare you
are using the more capable terminal type when you're logged into a
system that understands how to drive it (eg. the local system), and then
declare that you're using a subset of that terminal when you login to a
remote system, a subset that the remote system already knows how to
drive.

So, I would say the default terminal type for the wscons screens should
be whatever gives the best and most useful features for the NetBSD
applications.  If that means defining a new system-specific console
terminal type, then so be it.  Such a definition can easily be copied by
any user to almost any remote unix system and thus be able to use
applications on the remote system with the custom NetBSD console
terminal type.

In an ideal world wscons would implement _exactly_ some modern real
terminal that most systems already know how to drive/interpret
correctly, nothing more, nothing less, bugs and all.  I don't know what
terminal would be the best choice, but presumably it would be one
manufactured by the former Digital Equipment Corporation since they are
undeniably the most widely supported terminals.  Cerainly no other
emulator or system console that doesn't do exactly the same is really
appropriate to copy since they are all, pretty much by definition,
system specific hacks.  Too many incompatible options means too much
wasted code.  This is one place where doing only one thing, and doing it
exactly right, is the best course of action.

Assuming wscons implements a quite feature-rich termanal the only really
hard-to-solve problems occur with older remote systems and/or
applications which impose limits on the size of terminal capabilities
databases.  I don't know how important these older systems are to people
who might use the NetBSD wscons screens to access them.  Perhaps two
terminal descriptions could be provided for wscons, one which describes
the full capabilities of the implementation, and one which describes
just the minimal set of capabilities used by older curses applications.
Then users could use the latter to "teach" the older systems that impose
these size limits how to drive their screen and interpret their
keystrokes.  Unfortunately it seems difficult to get users, especially
modern users, to understand this mechanism of terminal types we use, and
to know how to identify problems with the way their applications are
attempting to drive their "screens".  

-- 
								Greg A. Woods

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