Skip site navigation (1)Skip section navigation (2)
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>