display vs video sync vs ^L

[Fairlight]

Y'all catch dis heeyah?  Kenneth Brody been jivin' 'bout like:
> 
> The O/S has no concept of what is on the screen.  Some screen managers,
> like "screen", _may_ keep track of this to enable multiple screens on
> one physical display.

"Screen manager" is really an inadequate way to describe screen(1).  At
any rate, it isn't just "may", it flat-out MUST keep that information.
Switching between multiplexed screens, copy for copy&paste from not only
the current screen but a scrollback line history, the presence of the more
modern doublevision/ttysnoop-like multiuser mode, etc., all necessitate
that it track this information.  

Each screen has a buffer associated with it, and any time you switch
between screens the parts of the buffers that differ are redrawn via curses
for optimal redraw speed.

It's had full screen buffer tracking since I started using it in '90 when
it was still hosted at cs.orst.edu, long before it went GNU.  I don't
recall it ever not having it, mostly because, being a multiplexer, it can't
do without it.  AFAIK, it's been that way since the very first release.

> > The sub process is getting run as user filepro.
> > This, (or something) causes the rclerk process to be unable to read or
> > write the tty the user is on.
> 
> I can't see how that is possible, as stdin/out/err are already open,
> and simply passed to the child process.

Sounds like someone's trying to use raw terminals when open fd's would
serve better.

m->
-- 
Try our new SPF-0 lotion, SunScream[tm].  Get it while it's hot!