> I *STRONGLY* object to the ability to add capabilities to the
> [terminfo] database.  I don't care if the database is one flat ASCII
> file, AT&T style directories, environment variables, or whatever, so
> long as the greatest practical efficiency is maintained.

I can't see any connection between those two sentences.  How does the
ability to add capabilities impair practical efficiency?

> This may have been a useful feature for the database maintainer back
> in the days when the problem of terminal independence was still being
> explored.  However, since that time each and every instance I have
> encountered where someone added a capability resulted in yet another
> totally incompatible database which required constant correction in
> synch with all the other similar databases.

I'm not sure what you're saying here.  It sounds as though you think
that everything that it could be useful to describe about terminals has
already been identified.  If so, I think you're wrong; it smacks rather
of the then-commissioner of the US Patent Office, in 1899, saying that
"Everything that can be invented has been invented.".  One thing the
inability to add capabilities _is_ sure to do is to cripple further
evolution.

As for your talking about "totally incompatible database"s, well,
that's exactly the problem with having a binary file format that isn't
key-value pairs: a database with something added is totally
incompatible with library code that hasn't.  If the file format were
saner, if it were key-value pairs, then databases could be shared
between libraries that know about "new" experimental capabilities and
libraries that don't.

As for "constant correction", anytime you keep two copies of an
evolving database, one of them needs constant correction if they're to
stay in sync.  Not much you can do about that.

> I would suggest the number of new unique terminals is effectively
> zero for the standard ASCII realm, vastly reducing the need of ever
> extending the database.

What about describing things that nobody thought to care about before?
To pick a simple example, does terminfo describe the character-cell
aspect ratio?  I doubt it.  And it matters to programs trying to do
ascii-graphics.

Also, what about beyond "the standard ASCII realm"?  For example, how
about capabilities describing which of the ISO 8859-* sets are
available and how to display them?  One describing which non-ASCII
printable characters are available on keys of their own, and which
others are available via special shift keys and/or via compose-key
sequences?

> I would also suggest that international users should eagerly send
> their contributions to the ncurses maintainers in order to avoid
> further need for local hacks.  They should also be pushing for
> acceptance of these same features by X/Open.

Perhaps, though I daresay most of them have no contact with X/Open; I
certainly know I have no idea whom I should tell if I want to push for
X/Open to do something.  Nor do I have any reason to think they'd care
about my pushing.  But if I were to implement something, and enough
people found it useful, then it would become "current practice".  If
you look at the history of standards, the useful ones are those that
standardize current practice instead of trying to standardize before
practice settles.  Pushing to get something standardized before it has
been shaken down in real use is a big mistake.

Yes, people who find that curses and/or terminfo (and/or termcap, for
that matter) should be pushing to get curses/terminfo(/termcap)
extended.  But there's no reason to make it hard for them to experiment
with extensions to find out what extensions actually work.

Personally, I think the biggest problem with terminfo is that it has no
analog of putting the termcap entry itself in $TERMCAP.  With termcap,
you can put a terminal type in $TERM and its termcap entry in $TERMCAP,
and termcap-driven programs work just fine without your needing to frob
anything in the filesystem.  AFAIK terminfo has nothing analogous.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu