Re: terminfo vs termcap

[christos%astron.com@localhost (Christos Zoulas)]

In article <20090605154831.GC24820%sirion.coris.org.uk@localhost>,
Julian Coleman  <jdc%coris.org.uk@localhost> wrote:
>Hi,
>
>> 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 did wonder about creating a terminfo compatible part of our libterm.  This
>would allow us to support those extra terminfo calls that are not in the
>current libterm.  The most useful one to me was tparm().
>
>I was thinking of still using termcap as the back end.  Basically, the
>compatible part would have a mapping between terminfo and termcap
>capabilities.  For example, if you called:
>
>  tigetstr("cud");
>
>it would translate internally to:
>
>  t_getstr(tc, "DO", NULL, l);
>
>(Functions without a termcap mapping would be extra).  That wouldn't involve
>any changes to the curses library.
>

I think that is probably the easiest way; the terminfo API is also ancient,
deficient and ugly:
    - can only handle one terminal at a time
    - does not use const, and tparm is just nastyness that could have used
      stdarg.h

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

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

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?

christos