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