terminfo, termcap, etc

[BALDWIN]

>While I won't dispute the claim that terminfo is more expressive, I
>still find it to be a HUGE step backwards in design: there just isn't
>sufficient justification for making the active, working database a
>compiled binary file

Oh, reading a 70K file and parsing it each time is faster than reading
in an already-parsed binary file?  I find terminfo a huge step forwards
in design.

>-- PARICULARLY when AT&T then doesn't include the
>sources to the terminfo descriptions. As shipped, the description for
>the DMD5620 is noticibly broken. To fix it, I'll have to completely
>rewrite the entire thing, since the readable (modifyable) version isn't
>available.

Give me a break.  The format is documented and easy to parse, and anyway,
with SVR3 you get the infocmp(1) program, which dumps a terminfo entry
in a form suitable for editing and recompiling via tic(1).  What the
hell more do you want?  And my 5620 terminfo entry works fine (I'm using
it right now).

>Termcap isn't as expressive, perhaps, but I can write and
>modify termcap descriptions easily.

$ infocmp >file; ed file; tic file
Real difficult.  Terminfo just beats the pants off termcap;
the sooner termcap disappears the better.
-- 
						Michael Baldwin
			(not the opinions of)	AT&T Bell Laboratories
						{at&t}!whuxl!mike