On Fri, Jun 05, 2009 at 04:34:20PM -0400, Christos Zoulas wrote:
> 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.
oh. termcap can't do that either (unless you're talking about a different
implementation from that which everyone else uses).
It's not here, at any rate:
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libterm/termcap.h?only_with_tag=MAIN
> | > - 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?
#define/#ifdef
> | > 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.
OpenBSD's used ncurses with (their patch for) hashed-db for quite a while.
ncurses has its own implementaton for a few years -
http://invisible-island.net/ncurses/announce-5.6.html
> | > 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.
An example of a missing one would be useful for the purpose of discussion...
> | > 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.
Probably not (termcap simply can't represent a lot of the terminal descriptions
which exist in terminfo).
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Attachment:
pgpEH2ScCS7_B.pgp
Description: PGP signature