This document assumes the reader is familiar with "ECCE" and has
a passing knowledge of screen editors.

 ** need section on design choices for display behaviour

The display in VIDE is implemented very simply; first a procedure is
written which would print out the file as if the editor were not a
screen editor.  This handles tab stops, plus a representation for
binary characters.  (It also handles line wrapping at the window
width explicitly, in case a display does not automatically wrap to
a new line on hitting the RHS of the display)

The actual screen is considered to be a sliding-window cursor (imagine
an old-style slide rule, held vertically) which is moved around so
that it always contains the point of focus of the editor.

A "preferred display line" is maintained, and the sliding window
is positioned so that the preferred display line coincides with the
focus.  If putting the focus on the preferred line would cause the
first line of the file to be anywhere lower than the first line of
the display, the preferred line is moved up by the appropriate
amount so that the first line of the file is the first line of the
display.

Movements such as "cursor up" alter the preferred display line,
but the preferred display line is always constrained to be within
the range of the display.

The effect of this is that hitting cursor up will move the cusor up
the screen until it hits the top, then the page contents will scroll
down rather than the cursor moving up.  This is all transparent to
the editor and does not require special case code.


This editor uses ECCE for all data manipulation.  The ECCE commands
have no knowledge of the screen.  Executing the ECCE command "m-"
to move up will not alter the "preferred display line" variable;
instead of the cursor movinf upwards, the page contents will move
downwards - if they can (bearing in mind that the top of the fie
is anchored to the top of the display)

'immediate commands' are all handled outside ECCE (from VIDE)
and those _do_ handle screen cursor movement.

Printable characters are sent to ECCE; all other key presses are
immediate, so screen movements are like a 'traditional' screen
editor; it is planned that all keys can be bound to an ECCE action,
so that for example typing a letter will self-insert that letter,
eg "x" invokes the ECCE command "i/x/".  If this mode is active,
the only way to enter ECCE commands will be to prefix them with
an escape character.

The Ecce command line is displayed by shrinking the window size
by one, while leaving the preferred display line the same.  Only
if the preferred display line is the last line on the screen (where
the ecce command is echoed) will the display temporarily scroll up
one line.

Errors are also reported on that same line, and disappear with the
next keypress.

Both of these mechanisms are cheap to implement and require no
special-case code.