Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 5/22/85; site cbosgd.UUCP
Path: utzoo!watmath!clyde!cbosgd!mark
From: mark@cbosgd.UUCP (Mark Horton)
Newsgroups: net.unix-wizards,net.unix,net.info-terms
Subject: Re: Terminfo()--Ideas needed. System V
Message-ID: <2145@cbosgd.UUCP>
Date: Sun, 18-May-86 01:54:13 EDT
Article-I.D.: cbosgd.2145
Posted: Sun May 18 01:54:13 1986
Date-Received: Mon, 19-May-86 04:42:51 EDT
References: <1135@bunker.UUCP> <155@molihp.UUCP> <2774@pegasus.UUCP> <1553@ecsvax.UUCP>
Organization: AT&T Bell Laboratories, Columbus, Oh
Lines: 69
Xref: watmath net.unix-wizards:18105 net.unix:7889 net.info-terms:966

In article <2774@pegasus.UUCP> hansen@pegasus.UUCP (Tony L. Hansen) writes:
>... More to the point, when will Berkeley support terminfo? ...

The real question here is, when will AT&T let Berkeley use terminfo
and the rest of System V.  There are apparently some amazing legal
discussions going on.  Berkeley has been interested in terminfo since
1982, but they just haven't been able to include it without either
requiring a System V license or getting sued.  There turned out to be
a lot of problems with requiring their users to get a System V license.

In article <1553@ecsvax.UUCP> bet@ecsvax.UUCP (Bennett E. Todd III) writes:
>While I won't dispute the claim that terminfo is more expressive, I
>still find it to be a HUGE step backwards in design:

Everyone is entitled to their opinion, of course, but I think Mr. Todd is
primarily annoyed because he has managed to get a binary-only system.  I
can understand his frustration at trying to use a UNIX without sources,
and not just with terminfo.  If he had source, he could look in
/usr/src/lib/libcurses/terminfo for the sources.

As to the problems with the 5620 description, it turns out that the
version of curses/terminfo in System V Release 2 was frozen in April
1983, and I think the 5620 was just coming out at the time.  There
may be differences between the version of 5620 ROMs you have and the
terminfo that happened to come with your system.  It's easy enough
to fix, with or without source, in release 3 using infocmp (an amazing
program, which slices, dices, diffs binaries, uncompiles, and translates
between termcap and terminfo.)

To set the record straight, the public domain terminfo curses that
Pavel Curtis wrote was written entirely by him.  I was not involved
in it at Berkeley or at Bell Labs.  I did, however, write the System
V release 2 version.  (The release 3 version had input from me, but
several others did most of the work, making major enhancements.)

By the way, the person who rewrote libtermcap to have one for the
public domain wasted their effort - the original implementation, from
Berkeley, has always been public domain.

The complaint that tic doesn't find syntax errors in terminfo descriptions
is amusing, especially when it appears to be used as the basis for an
argument that termcap is better than terminfo.  Either syntax would
permit an error checking implementation, although I don't know if you'd
want the syntax checked every time vi started up :-)  The SVr2 tic
was just a modified version of the termcap file reading code, which
also doesn't notice syntax errors.  The SVr3 tic is completely redone
(it's based on Pavel Curtis's tic) and is fairly fussy about syntax
errors.  It's also more complete, uses the existing binary database,
and is much faster.

I think when comparing termcap to terminfo, the real differences are:

(1) terminfo has more capabilities, although most of these can be ported
    back to termcap without too much trouble.
(2) terminfo can do some things termcap can't, e.g. tparm is fundamentally
    more powerful than tgoto.
(3) terminfo does more at compile time, so it's better for a production
    environment.
(4) termcap is more like an interpreter, so it's a bit more convenient for
    a development environment.
(5) it's easier to dynamically construct a termcap description and put it
    in the environment than a terminfo.  This happens to matter for one
    telnet-like program at MIT that emulates the subset of a standard
    terminal whose functiona match the hardware you have.  It would also
    matter for a window manager (where the window size can vary) if it
    weren't for features designed to let you override the lines/columns
    capabilities.

	Mark Horton