Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 8 Apr 1996 15:36:07 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        esr@locke.ccil.org (Eric S. Raymond)
Cc:        ache@astral.msk.su, scrappy@ki.net, current@FreeBSD.org, ncurses-list@netcom.com
Subject:   Re: terminfo-less ncurses
Message-ID:  <199604082236.PAA03229@phaeton.artisoft.com>
In-Reply-To: <199604081717.NAA08172@locke.ccil.org> from "Eric S. Raymond" at Apr 8, 96 01:17:07 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> Andrew Chernov writes:
> > Terminfo abuses filesystem with its database, Berkeley *.db termcap database
> > give much faster results for searches. Terminfo is not extendable.
> > Modern termcap have all terminfo cababilities.
> 
> I totally disagree.
> 
> 1. The terminfo database is no more an `abuse' of the filesystem than home
> directories are -- both cases legitimately use the filesystem for name lookup.

The directory lookup is nessary because of the (stupid) idea of a
per process current directory in the kernel.

The terminfo lookup is is lieu of an index file, and makes an operation
that should be O(log2(n)) into an operation that is O(n/2).

Use of the file system in this way is a bad idea.  No one is arguing
that it doesn't work, only that it is repugnant.


> 2. The alleged higher speed of 4BSD search is a red herring -- the proper
> figure to look at is the entire load time per entry, and terminfo wins on
> this one because the capabilities are pre-digested.

Which makes for a fixed on disk structure (read non-extensible) which
means we are egotistically sure that we have definitions for all the
capabilities that anyone is ever going to need or invent.

> 3. The supposed non-extendibility of terminfo is a non-issue.  Nobody
> has seriously proposed any termcap extensions other than those intended to
> mimic terminfo for many years now.  Terminfo suffices -- and, if it did not,
> it does in fact have some extension capability.

I propose input automaton grammers to allow for zero state crossing
information to be used for function key interpretation, session
switching on paged terminals, and transparent printing that will not
prevent normal use of the terminal.

> 4. Modern termcap has nowhere *near* the capabilities of terminfo, as I
> know for certain because I have had to become intimately familiar with both.

SCO lists equivalent capability descriptors for termcap for each and
every capability supported by terminfo.

The VT100-specific graphic cahracter strings for boxdraws in terminfo
and the 7 color limited color pallete for ISO color sequences is very
limited.  This is annoying.

> > Total terminfo disabulity isn't possible with current ncurses,
> > so additional patch needed. If it will be configure option,
> > it will be even better.
> 
> So far, I see no case whatsoever for keeping termcap alive.  Nor does
> Keith Bostic, who wrote and maintained the 4.4BSD implementation.  You'll
> have to work pretty hard to make such a case.

You misunderstand.  We are not saying that termcap isn't crap.  We are
saying terminfo *is*.  Just because we oppose your position doesn't
mean that we support that of the only opponent you choose to recognize.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604082236.PAA03229>