Greg A. Woods wrote:

> [ On Saturday, April 24, 1999 at 23:37:27 (+1000), Simon Burge wrote: ]
> > Subject: Re: A solution for termcap lossage? 
> >
> > 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.
> 
> If you can seriously find something that *really* needs a new capability
> in order to be made to work -- i.e. something critical to the correct
> operation of a screen-based application, not just some new and fancy
> bell or whistle -- I'll be really surprised.

The example I was told of was i18n support - I didn't actually see a
concrete example though.

> > The argument of "terminfo databases taking up loads of inodes" is an
> > implementation issue. ncurses is happy to run with just a termcap file
> > (or termcap.db - it can use getcap() and friends).
> 
> Actually that argument is only really relevant in a historical
> perspective.
> 
> I've got so many spare inodes in all my 4BSD filesystems that it's just
> not funny (on a SunOS-4 system that already has terminfo installed I've
> more free inodes than kbytes of disk space on /usr!!!!) -- I could have
> a 100 terminfo databases and not even notice.  This argument *only* ever
> applied with SysV's filesystems.

The "standard" terminfo database has approx 1700 files.  Just seems a
bit wasteful to me.  Anyways, as I've said it's just an implementation
issue...

> As for handling >1KB termcap entries, well, one could argue that this is
> an API limitation that's been there from day one.

My argument is that there is no reason to keep this lossage if we don't
need to...  I'll conveniently ignore that terminfo doesn't have the
problem for now :-)

Simon.