Re: terminfo vs termcap

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

On Jun 5,  8:01pm, roy%marples.name@localhost (Roy Marples) wrote:
-- Subject: Re: terminfo vs termcap

| 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.

There are no arguments to pass to the put function to indicate where output
should go and there is a single global "current TERMINAL" state. An application
can open multiple ptys at the same time.

| >     - 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.

namespace?

| > 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.

Well, the spec does not but programs have all this info hard-coded in all
the implementations I've seen.

| > 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.

Well, we can find all the missing ones and define them.

| > 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.

I don't see why not. The parser for the terminfo files would turn them into
termcap at read time.

christos