Pagination in TTY driver

[zben at umd5.UUCP]

In article <124 at cithep.UucP> tim at cithep.UucP (Tim Smith ) writes:
>Time for a third point of view here.  Pagination belongs in the terminal!
>Note that the terminal already knows how many lines long the screen is.  It
>also knows what happens at the last column.  It alread knows about escape
>sequences recognized by itself, so it can deal with cursor addressing 
>programs. 
>
>And with what RAM prices have been doing, it is not unreasonable for a
>terminal to have lots of memory, so you can back up.  Besides, in the
>future, I think most "terminals" will be personal computers running
>terminal emulator programs. 
>
>While I'm at it, the terminal is also where history belongs...

I agree with the thrust of the arguments.  The latest complaint of my boss
is that his Zenith PC with Ethernet interface can dump stuff to the screen
faster than it can be read (by several orders of magnitude, probably).

After having talked him OUT of modifying every program in creation to meter
its output, and having convinced him that the place to solve the problem is
in the micro, your argument looks very good.  Most clones have oodles of
memory to spare when running terminal simulators.  Why not just accept the
hundred thousand bytes into memory directly, then either scroll them onto
the screen with keyboard control, or let the user page the screen up and
down in the circular buffer with the last 250,000 bytes received.

But, consider the difficulties of doing paging and history in the terminal
if a window environment is used.  You probably want to have N history streams,
at least one for each window running the shell, probably one for each window
in general.  The paging would also have to know which window is filling up,
and how big it is.  While one COULD extract this information from the
cursor addressing sequences on the fly, the principle-of-least-messiness
requires us to at least look at other solutions.

So, do all the window stuff in the terminal!  Tag output on the host-micro
link with which window it is destined for, and let software in the micro do
the actual screen management.  Since it knows which window the output is
for, it can do the MORE? stuff easily enough.  It could probably know enough
about where you are on the screen to determine which window you are typing
into, and know which history stack to pull from, push to, and use the same
information to tag incoming lines so the software on the host knows which of
the processes to which to deliver the input.

I dunno, just random thoughts.  I mean, I use a Volker Craig in ADM3 mode.
This window stuff is still hypothetical here...

-- 
Ben Cranston  ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben  zben at umd2.ARPA