[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: terminfo vs termcap
On Friday 05 June 2009 19:36:47 Christos Zoulas 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 must confess, I am fairly ignorant about curses.
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.
> - does not use const, and tparm is just nastyness that could have used
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, the
spec even goes to say that it deliberately doesn't mention how terminfo should
be compiled or stored, just the source format.
> 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
> 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.
Main Index |
Thread Index |