[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: terminfo vs termcap
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.
| > 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,
| spec even goes to say that it deliberately doesn't mention how terminfo
| 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
| exists. Whilst this doesn't seem to be much of a problem now it may in the
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.
Main Index |
Thread Index |