Re: terminfo vs termcap

[Roy Marples <roy%marples.name@localhost>]

On Friday 05 June 2009 19:36:47 Christos Zoulas wrote:
> >> So I looked into what we have, and I think we can do quite a bit by
> >> providing libterminfo to read the terminfo db's and provide termcap
> >> compat functions and a basic tic compiler to convert termcap(5) and
> >> terminfo(5) sources into terminfo.dbs. curses(3) would have to be
> >> re-tooled around libterminfo of course.
>
> That would be a regression, because then our curses library will not
> be able to handle multiple terminals from a single process. That is
> not too important, but nevertheless it is a regression.

I must confess, I am fairly ignorant about curses.
Why would a single process want to handle multiple terminals and why is this a 
terminfo limitation? Nothing stands out that says it cannot be done.

>     - does not use const, and tparm is just nastyness that could have used
>       stdarg.h

ncurses has two approaches to tparm - one is the long, long long which matches 
POSIX and the other is using variadic parameters. I see no reason why we 
cannot support both.

> The biggest advantages of terminfo were:
>     - no size limitation in the api for a terminfo entry
>     - more than 2 character names.
>     - % delay strings (IIRC)
>     - faster database lookups because each terminal description is in a
> single file

Nothing says that terminal descriptions have to be in single files. Infact, the 
spec even goes to say that it deliberately doesn't mention how terminfo should 
be compiled or stored, just the source format.

> None of those limitations apply to our termcap implementation, at least I
> cannot think of any:
>     - we have the extension escape, for things that need more than 1K.
>     - we don't really need this, the code seems to already support.
>     - I don't think that there are actual devices alive today that need
>       the delays.
>     - we use termcap.db

ZZ which we use for things >1K is
micro_down   mcud1   ZZ   Like cursor_down for micro adjustment
I don't know how important it is to support that, but by nature we cannot.

Also, there are now quite a few terminfo codes for which no termcap equivalent 
exists. Whilst this doesn't seem to be much of a problem now it may in the 
future.

> I think that most fuctionality can be achieved having a map that
> goes from terminfo names to termcap names, that is if we want to
> supply/support the terminfo API. Is there any other reason to want/need
> terminfo that I am missing?

Easier to support new terminal descriptions as all OS'es are on the same page 
is quite a good one.
Although the API would be supported, user defined TERMINFO files would not be.
I would rather try and fully support terminfo than halfway.

Thanks

Roy