Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site cisden.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!hao!nbires!boulder!cisden!lmc
From: lmc@cisden.UUCP (Lyle McElhaney)
Newsgroups: net.info-terms
Subject: Re: wishful thinking dept.
Message-ID: <293@cisden.UUCP>
Date: Wed, 6-Nov-85 23:20:57 EST
Article-I.D.: cisden.293
Posted: Wed Nov  6 23:20:57 1985
Date-Received: Sun, 10-Nov-85 07:18:13 EST
References: <292@cisden.UUCP> <2686@brl-tgr.ARPA>
Distribution: net
Organization: ConTel Information Systems, Denver
Lines: 59

>                             an updated manual entry is in
> the works which may make it into 4.3BSD.  An early version
> of this manual entry has been distributed with BRL software.
> 
Could you send me a copy? Thanks.

> However, it is true that there has been no consensus on
> capabilities for such things as box-construction graphics
> and color.  I believe Mark once mentioned that terminfo
> may support these at some future date; if we could all
> come to a consensus on what these capabilities are then
> termcap names for them could easily be invented (maybe
> adopt Lyle's) and added to the "official" description.
> 
Well, the convention I use was posted way-back by eric@aerospace, and
consist of the string variables Gs (into line-drawing mode), Ge (out
of line-drawing mode), Tl, Tr, Bl, Br (corners), Vl, Hl (lines),
Tj, Bj, Lj, Rj (joins; Lj is |-) Cj (center join, or cross) and Xc
(extra character, like diamond or box or other character available in
line-drawing mode). I haven't found a terminal with l-d yet that this
won't work with (except the execrable ADM-11, with magic cookies
to go in and out of l-d). Anyone have a counter example?

> There is of course a limit to how far the termcap model
> of a "terminal" can be pushed; it really cannot cope
> with true graphics, bitmaps, etc.  Terminfo has a better
> design for adding things such as multiple windows, etc.,
> but its underlying model is similar.
> 
Yes, absolutely. But termcap is more available (maybe because it is much
simpler to implement) than terminfo, and available on more machines. On the
restricted set of character-oriented terminals (still in the great majority)
it does excellently, providing the standard for adding/deleting/refining
caps is available. Its like the government mandating uhf receivers on TVs;
useless at the time, but now there is an audience for the uhf station. No
one will write software using new capabilities unless there is a guaranteed
"market" in which the cap is defined and exists in published termcaps. Same
goes for terminfo, by the way, as well as library routines etc etc.

> In general, termcap has enough significant design
> deficiencies that future efforts should be concentrated
> on terminfo instead.
> 
Yes, true. It may well even be too late for terminfo.

> > 	...looked for an entry in ~.termcap before running off to
> > 	   /etc/termcap?
> 
> The TERMCAP environment variable, while not accomplishing
> precisely the same action, is intended for this sort of
> thing.
> 
Yes, except that it useless when, after TERMCAP gets properly set, you
need to execute tset (or reset) to get your terminal back after an
accidental insanity. The reset strings in the published termcaps are often
too "weak" to correct things, but I can't get to my own...

Lyle McElhaney
...cisden!lmc