tech-userlevel archive

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


Home | Main Index | Thread Index | Old Index