🚀 go-pugleaf

In article <2921@kraftbus.cs.tu-berlin.de> net@opal.cs.tu-berlin.de (Oliver Laumann) writes:
> In article <1991Mar19.164204.21361@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes:
> > Why do you say screen is less flexible when using terminfo?  Why
> > change the terminal definition on the fly?
> 
> Because the capabilities of the virtual terminal that is emulated by
> screen depend on the capabilities of the physical terminal on which
> screen has been started.  Example: screen cannot emulate the "blinking"
> attribute if the physical terminal doesn't support this capability.

Ah, now I see the dilema.  I had assumed that screen wasn't actually
trying to emulate some virtual terminal, but rather just providing
windowing, and allowing curses to use the existing terminal definition.

I can see the advantages of doing this, but it does seem to be overly
complex, especially given that screen isn't (so far as I know)
advertised as providing more intelligent virtual terminal emulation
for really dumb terminals.

On the other hand, for terminfo, instead of being able to dynamically
define the terminal capabilities, why not logically break down the
various categories of support such that a set of extended terminfo's
can be built around a default minimum terminfo description.  (Eg.: if
"scrn" is the default, "scrn-noblink" could be the terminal type used
when the physical terminal doesn't support blinking.)

Of course the dynamic construction of the terminfo description will
still work, but it requires writing the description out to a temporary
file, then running 'tic' (with the environment variable TERMINFO set
to some writable directory).
-- 
							Greg A. Woods
woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP		ECI and UniForum Canada
+1-416-443-1734 [h]  +1-416-595-5425 [w]  VE3TCP	Toronto, Ontario CANADA
Political speech and writing are largely the defense of the indefensible-ORWELL