Date: Wed, 10 Apr 1996 15:17:25 -0700 (PDT) From: Kaz Kylheku <kaz@cafe.net> To: Terry Lambert <terry@lambert.org> Cc: "Eric S. Raymond" <esr@locke.ccil.org>, terry@lambert.org, ache@astral.msk.su, scrappy@ki.net, current@FreeBSD.org, ncurses-list@netcom.com Subject: Re: terminfo-less ncurses Message-ID: <Pine.LNX.3.91.960410150803.12049B-100000@latte.cafe.net> In-Reply-To: <199604090040.RAA03591@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 8 Apr 1996, Terry Lambert wrote: > Date: Mon, 8 Apr 1996 17:40:22 -0700 (MST) > From: Terry Lambert <terry@lambert.org> > To: "Eric S. Raymond" <esr@locke.ccil.org> > Cc: terry@lambert.org, ache@astral.msk.su, scrappy@ki.net, > current@FreeBSD.org, ncurses-list@netcom.com > Subject: Re: terminfo-less ncurses > > > > 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. > > Terminfo can't dictate file system semantics or implementation. It > should not. Even if I think FS's should use btree's for name lookup, > the fact is that some do not, therefore it should not rely on that > behaviour. > > You might as well make each terminal type a directory instead of a file, > and make each capability a file, and make each file contain one escape > sequence/whatever. > > > > > 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. > > I don't think it is significantly faster. We have moved from "most > machines are compute bound" to "most machines are I/O bound" in the > last 10 years since terminfo was first invented. One block read is > very much like another: it will take the same time in either case. > > The overhead of post-processing the file format into something usable > by tputs() in the tgetent() code was an argument for a Tandy 6000; > it is much less of an argument for a 90MHz P5. > > > > 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. > > Again, terminfo is itself more than 10 years old. Relative age is not > a good argument. I think terminfo is an idiotic idea. I can pop /etc/termcap into vi and make a change that I need. Since my system is not likely to support terminals other than vt100, I can trim it down easily, or put the most common terminals at the beginning. Also let's not foget the TERMCAP environment variable! Any curses program that doesn't recognize this variable is broken. I can telnet to a remote host, and pop my local console termcap entry into /etc/termcap (or have root do it), or I can assign it to TERMCAP, and I'm on my way... Binary configuration files are not the UNIX way of doing things. I don't have a ``compiled'' /etc/hosts /etc/fstab or /etc/rc.boot, do I? Terminfo is a PITA. Pain In The Arteries. Today's UNIX systems could crunch through an 8 megabyte /etc/termcap each time you run a curses program and still start up the program faster than Microsoft Word. > If you could show me that the terminfo format had not changed since > day one, well, then you'd have an argument. Haha. Touche.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.91.960410150803.12049B-100000>