Subject: Re: A solution for termcap lossage?
To: Simon Burge <simonb@NetBSD.ORG>
From: Brett Lymn <email@example.com>
Date: 04/26/1999 21:00:08
According to Simon Burge:
>The main reason for looking at ncurses was that it is currently actively
>maintained, and that it had changed maintainers and was still going
>forward. BSD curses didn't appear to be at that stage. It also was at
>the stage (or close too) of standards compiliance.
Julian and I are working towards standards compliance as a goal. We
are looking at what functions would serve NetBSD best by being
>A major stumbling block for ncurses was that it's internal terminfo
>representation didn't allow for extension to terminal attributes. For
>example, you couldn't add a "zz" capability, even when in "termcap
>compatibility mode". The current maintainer has stated that this will
>be a goal _after_ the next release of ncurses.
I do not believe that this will be a problem :-)
>The argument of "terminfo databases taking up loads of inodes" is an
Just for the record, I simply think the "normal" way the terminfo
database is implemented is ugly (just my opinion ;-). It has the look
of a "good idea at the time" and there would need to be very strong
arguments for perpetuating it which I have not seen yet.
>I like Christos' idea of a new threaded-friendly API,
So do I, so much so I think I shall implement it.
> but I think we
>need the old API to handle >1kB termcap entries without the need to
>change third-party source.
Hmmm I was thinking of just leaving the old calls as wrappers and
truncating the termcap entry at the 1023 mark. Currently tgetent does
force a truncation. If the termcap entry is ordered right then the
"important" capabilities should be below the limit and the larger
capabilities, such as colour support, are at the end.
> Something that comes to mind is to store a
>pointer to a larger buffer (if needed) in the last sizeof(ptr) bytes
>(maybe preceded by a magic number of some sort) at the very end of
>the user-supplied 1kB buffer. User supplied code scan still manually
>look at the first 1kb-sizeof(ptr)-sizeof(magic)-NUL characters of the
>buffer - I'm sure I've seen some game source do this instead of using
>tgetstr(), tgetnum(), etc.
And still have all the capabilities for people who use the library
interface with the old calls. I think that this could work.
> I guess that this has the drawback of memory
>management - at the moment the user doesn't have to tell the library
>when it's finished with the termcap buffer... If you like this idea I
>can work on it more (more than the few minutes I just put into it!).
This is true but the drawback is small since a) the termcap entry is
not likely to be huge, I would say less than 10kB and b) tgetent is
not normally called more than once in the life of a program.
>If we are going to junk of the idea of ncurses altogether, maybe it
>would also be worth adding a terminfo API as well. This may be of
>limited value (most code probably starts out as termcap based), but
>you never know.
I was thinking of adding the terminfo api. I did propose before that
both the termcap & terminfo functions could reference the same
capabilities database and spit back the appropriate response style
depending on the call used.
>It doesn't worry me either way if we move to ncurses or update BSD
>curses. As long as we're moving forward, I'm happy (and happy to help
Needless to say both Julian and I are keen to get BSD curses up to
scratch. Any help and/or suggestions are most welcome :-)
Brett Lymn, Computer Systems Administrator, British Aerospace Australia