Date: Mon, 8 Apr 1996 17:40:22 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: esr@locke.ccil.org (Eric S. Raymond) Cc: terry@lambert.org, ache@astral.msk.su, scrappy@ki.net, current@FreeBSD.org, ncurses-list@netcom.com Subject: Re: terminfo-less ncurses Message-ID: <199604090040.RAA03591@phaeton.artisoft.com> In-Reply-To: <199604082331.TAA25937@locke.ccil.org> from "Eric S. Raymond" at Apr 8, 96 07:31:12 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. 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. Terminfo has the same drawbacks, with the exception that people *think* they know what they need for a logicially complete implementation now. Terminfo, like termcap before it, only fixes half of the problem: it models output behaviour, and doesn't account for multiplexed channels with channel switching only allowable at the ground state. VMS is more advanced in that regard, and I wouldn't wish their implementation on anyone (DEC does not even use it internally: they hard-code their own products). Extensibility is still a good argument. Consider page flipping in xterm: not an issue on the table when terminfo was introduced. If you could show me that the terminfo format had not changed since day one, well, then you'd have an argument. > 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. I don't see a working "transparent print" capability. And Wyse-50's still outsell all other individual terminal types for point-of-sale applications (and the closest thing to a standard they have is the Televideo/Adds-VP). You might as well say "screw the capability database" and go to requiring ANSI terminals, like DEC did. Why have a capability database at all if all the world ANSI? > > 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? Yes, I have. They do not insure the terminal is at state zero before allowing themselves to be used. You can work around this by building an automaton into the driver that mimics terminal state (using a much more logical modelling mechanism than either termcap or terminfo), like Digiboard and Computone and Arnet (etc.) did in the late 80's. Or by hardcoding ANSI into the terminal device drivers, like DEC did. Failure to do something like this means that a screen display process may send "esc [" out of "esc [ 2 J" and then the "transparent print on" sequence will be sent, followed by data, followed (somewhere) by a "2 J" in the data stream. Since on an ANSI terminal, an "esc" inthe middle of an "esc' sequence prior to a terminator (like "J") sets the state back to zero, you will end up with a screwed up screeen and no printer output. Brilliant idea, those useless-to-anything-but-specially-written-apps "mc* terminfo entries. NOT. > 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 propose that it should be abstracted, as it was in SCO and Interactive UNIX, needing a utility to sit between the real tty port and the session management software to encapsulate state information. Just like VT3xx series terminal work with LAT to talk to a DECServer 200 to implement session switching. Again, you are incorrectly mixing the idea of input vs. output processing. Both termcap and terminfo are good at output processing. Though termcap, because it is extensible, is better than terminfo, given the argument that antything that works is better than anything that doesn't (Occam's Razor). Neither are very good at input processing, and neither maintain sufficient state information to allow multiplexing output to a terminal that is capable of it. Page flipping in xterm is a minimally stupid application, and is not true multiplexing. I can't switch between my vi session and a shell prompt without making vi do the work, and even then, shell output can't occur while vi is processing (or vice versa). > I don't understand what "zero-crossing information" is in this context. Switching serial port data for a terminal to output to an alternate screen page or to a printer port is only possible if you know the terminal state to be at zero, since partial escape sequences are, by definition, errors. If it's helpful, think of it as a protocol issue, where you can only send certain packets at protocol state 0, and some packets will set the state to greater than 0, disallowing other packets from being processed. > 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. Consider a standard "VT100/ANSI/ECMA-48 clone". A VT102P (VT100 + 2 for AVO + P for printer port). Show me a method using the terminfo information where an application not using terminfo can reliably provide a loopback hook for a /dev/printer (the print equivalent for /dev/tty) such that I can start a print job on the transparent printer port and 100% reliably not have the transparent print sequence sent in the middle of an application escape sequence. Say I want this because I'm going to use the terminal with a receipt printer for a point of sale system, and I'm using Microsoft BASIC for SCO UNIX, and I know that the screen manipulation commands are sent as seperate writes per character (so you can't rely on an escape sequence being atomic across kernel calls). The ONLY way to do this reliably today is to use a driver with a finite state automaton that tracks the terminal state and does transparent printing as "start -- data -- stop" as atomic operations so as to avoid one application trying to talk to the user on the display on the serial line from screwing with the other application trying to talk to the printer on the same serial line using terminal state settings to multiplex the line. So nuts to both terminfo and termcap. They both suck at being able to do this. But if I wanted to, I could make a termcap entry pointing to a file describing an automaton, whereas to do the same thing for terminfo would require recompiling nearly every applciation because I'd have to change the terminfo structure to add the entry. > > 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. So we agree that curses needs to be fixed. 8-). I knew that when I gave up on using curses to emulate AM terminals on non-AM terminals for the only commercial product that ever emulated one kind of terminal on another kind of terminal without resorting to graphics modes or protocol conversion hardware. You're not the only one who has been deep into that code... > > 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. And going to terminfo does? The problem really wants to be "mapping to all available Unicode characters simultaneously displayable by the terminal", not "here are some chincy box-draw characters which are supported by VT100's and may show up as '|', '-', or '+' for you, lump it". The color model needs to be NP-complete to allow representation of other color models. > > > 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. Fine. Drive in the stake. But do so only after you've corrected the terminfo extensibility problem... otherwise, you've traded a slow-but-usable standard for a questionably-faster-but-largely-unusable one. A bad trade. Personally, I'd prefer to elect a new leader before putting the old one up against the wall. Even if you are a member of the opposition party and are trying to replace the old leader with another old, bald guy for technically obsolete reasons. This doesn't mean I'm in any hurry to give the old leader the bum's rush, mind you... to throw him out at all, you need to show the clear superiority of your proposed replacement. Regards, 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?199604090040.RAA03591>