[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: terminfo vs termcap
In article <20090605154831.GC24820%sirion.coris.org.uk@localhost>,
Julian Coleman <jdc%coris.org.uk@localhost> 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 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:
>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
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
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
- 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?
Main Index |
Thread Index |