Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.sources.d
Subject: Re: Screen 2.0 change
Message-ID: <15342:Mar2514:12:3091@kramden.acf.nyu.edu>
Date: 25 Mar 91 14:12:30 GMT
References: <1991Mar19.164204.21361@eci386.uucp> <2921@kraftbus.cs.tu-berlin.de> <1991Mar24.200524.13960@eci386.uucp>
Organization: IR
Lines: 26

In article <1991Mar24.200524.13960@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes:
> I can see the advantages of doing this, but it does seem to be overly
> complex, especially given that screen isn't (so far as I know)
> advertised as providing more intelligent virtual terminal emulation
> for really dumb terminals.

Well, it doesn't work on *really* dumb terminals, but it does an
excellent job of turning anything else into a VT compatible.

> On the other hand, for terminfo, instead of being able to dynamically
> define the terminal capabilities, why not logically break down the
> various categories of support such that a set of extended terminfo's
> can be built around a default minimum terminfo description.  (Eg.: if
> "scrn" is the default, "scrn-noblink" could be the terminal type used
> when the physical terminal doesn't support blinking.)

I've been working with a few other people on something like this. We
reduced terminal features pretty quickly to ten basic categories, with
three levels of support in each category. It doesn't seem to get any
simpler than that: whenever we try to combine two categories or
eliminate a level of support, we find some terminal that can handle one
of the original categories but not the other. So I don't think your idea
would work: terminfo's centralized setup simply cannot handle ten
independent options as well as termcap's decentralized configuration.

---Dan