Subject: Re: wscons termcap entry
To: Noriyuki Soda <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 07/04/2002 14:03:10
[ On Thursday, July 4, 2002 at 18:24:28 (+0900), Noriyuki Soda wrote: ]
> Subject: Re: wscons termcap entry
> >>>>> On Wed, 3 Jul 2002 22:44:45 +0200, Joerg Klemenz <firstname.lastname@example.org> said:
> >> 1) terminfo is not extensible the way termcap is. with termcap, you can
> >> add arbitrary capabilities. you cannot do this with terminfo.
> > What capabilities you want to add that won't work with terminfo??
> *Every capability*.
> Please look at binary format of terminfo carefully.
The binary format of compiled terminfo entries is only due to an
implementation detail (and is only necessary for backwards compatability
with binary-only applications). Even the need to compile terminfo
entries into a binary format is only an implementation detail, not a
requirement or limit to terminfo. Terminfo implementations can easily
(even trivially) be made to be extensible.
> Both termcap and source format of terminfo use "key=value" format,
> so different vendors can add new capability independently, if their
> key names don't conflict.
So goes it with any user-extensible object.
Naming conventions should be documented by the OEM so that third party
developers can choose non-conflicting capability names. Once upon a
time it was sufficient to simply declare that all uppercase termcap
capabilities were vendor-specific.... :-)
> But binary format of terminfo doesn't have key field.
> So, everytime one vendor add a new capability, that capability
> conflicts with capabilities of all other vendors with that offset.
> Such conflicts actually happened on commercial Unix vendors... ;-<
That is only a problem if you use the binary format _and_ you need
binary compatability for applications. That's not a fundamental
requirement of terminfo per se.
The default capabilities defined by terminfo are far better designed for
the purpose of describing modern "dumb" terminals and by default start
out with far more aesthetic and meaningful naming conventions....
Greg A. Woods
+1 416 218-0098; <email@example.com>; <firstname.lastname@example.org>
Planix, Inc. <email@example.com>; VE3TCP; Secrets of the Weird <firstname.lastname@example.org>