display vs video sync vs ^L

[Fairlight]

At Wed, Jan 17, 2007 at 10:49:08AM -0500 or thereabouts, 
suspect Kenneth Brody was observed uttering:
> 
> When I first came across it, or something similarly-named, many years
> ago, it did not auto-draw the screens.  When running filePro within
> it, a screen switch necessitated a Ctrl-L to refresh the screen.  Now,
> if the terminal itself supported multiple screens, and the termcap
> was written correctly, it would use the terminal's screen memory to
> handle this.  (I forget which termcap entries define this.)
> 
> It may be that today's versions do handle this (or at least attempt to
> handle it as best they can), but this has not always been the case.

I don't know what you used, but it doesn't sound like screen.  That would
no more happen with fP than it would vi, elm, pico, emacs, or any of the
other myriad programs I was running under it back in the day.  And I know
that those all worked just fine.
  
Likewise, even "window" (which I only ever saw on BSD 4.3) also worked just
fine.

I used window in '89 and screen starting in '90, and the only time I ever
recall needing a redraw of anything was if I got a write(1) or wall(1) over
the top of my screen.

There is -one- thing that might have caused this problem for filePro
in specific, and it just dawned on me.  Back in the day, screen was
7-bit only.  It wan't made 8-bit clean until somewhere in the 3.x series
somewhere around '97 or so (it's in that neighborhood, give or take 2
years).  If fP was using 8-bit all along, there's where the problem likely
lay in the past.

That doesn't negate the fact it has -always- had buffers for each screen.
It just says that the buffers were not 8-bit compatible.  A nuanced
distinction, but given your original statement, a pertinent one.

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