Date: Mon, 8 Apr 1996 19:31:12 -0400 (EDT) From: "Eric S. Raymond" <esr@locke.ccil.org> To: terry@lambert.org (Terry Lambert) Cc: ache@astral.msk.su, scrappy@ki.net, current@FreeBSD.org, ncurses-list@netcom.com Subject: Re: terminfo-less ncurses Message-ID: <199604082331.TAA25937@locke.ccil.org> In-Reply-To: <199604082236.PAA03229@phaeton.artisoft.com> from "Terry Lambert" at Apr 8, 96 03:36:07 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert writes: > 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. Sorry, I don't buy it. The file system is *supposed* to be a namespace manager -- that's one of its major jobs. If using the directory structure for name lookups really slows terminfo down, the right thing to do is speed up directory lookup in general, not object to terminfo's use of it. > > 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. It's a tradeoff; termcap's extensibility versus terminfo's improved load speed. When termcap was designed many years ago, there was no consensus on what a "smart terminal" ought to do, let alone what control sequences it should recognize; thus, designing termcap for extensibility made sense. In today's environment of a rapidly shrinking inventory of terminal types dominated by the ANSI standard, "egotism" about the scope of future terminal descriptions is quite justified. > > 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. Transparent printing? Ever seen the mc* terminfo capabilities? Session switching on paged terminals? Oh, you mean like the way the standard xterm entry and many others use smcup/rmcup to go to an alternate page when jumping to screen mode? Well, now...it's fairly hard to see what better "support" you could ask for than terminfo already has. OK, suppose you defined a standard go-to-page-N capability...how do you propose the curses machinery should use it? I don't understand what "zero-crossing information" is in this context. But these are details. Show me a new terminal that can't be described essentially completely by terminfo. Go ahead. Try. They're just not building weird command sets like they used to -- async-terminal technology now consists of 99% VT100/ANSI/ECMA-48 clones and 1% fossils. > > 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. True, but not quite to the point. No termcap-based curses library can use more than about a sixth of those. Trust me on this, I've been into the guts of AT&T curses, BSD curses, PDcurses, and GNU termcap deeper than anyone but their maintainers. > 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. Again true, but going back to termcap cannot solve this problem. > > 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. Now you've changed the ground of argument. If you want to write a new terminal-description formalism that solves all the world's problems, go ahead. I think it'll be a colossal waste of time, myself. All I'm concerned with in this context is driving a stake through termcap's heart as rapidly as possible. -- >>esr>>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604082331.TAA25937>