Foundation User Interface Support
		Design Document

INTRODUCTION

	Although Foundation is to be released with a user interface,
one of its purposes is the exploration of new ideas in user interface
design.  To this end, the first user interface is built on top of
systems designed to support multiple user interfaces.

	By definition, the user interface is how data is taken from
and presented to the user.  Foundation is built on the X window
system.  This means that a few restrictions are imposed.  For example
windows overlap by default and such features as tiling
(non-overlapping windows that resize in real-time) are harder to
implement.  It also means that a great amount of functionality is
available.  Windows and menus can be popped up easily and quickly.
Multiple fonts can be used.

	Foundation has a central data structure that records what
windows are present and active.   Modules doing user interface tasks
access that structure.  The modules can decide where to position new
windows, and have a great deal of control over what is done.
Presentation is therefore largely up to and easily controled by a user
interface module.

	For doing input and output there are two structures: the input
structure and the presenter structure.  For every different source of
handling input, there is an input structure.  The input structure has
a file descriptor, a flag which tells whether input is coming from a
file (simplest case), a stream (requires non-blocking input and use of
select), or a window (requires an event handler and a mouse handler),
a parser (which performs transformations on input text, and performs
functions), and if the source is a window, an event and mouse handler.

	For output the presenter structure contains a file descriptor,
and a presentation routine which transforms output so that each kind
of output can be formatted specifically for the output destination.
The presentation routine is a combination device handler and final
pass formatter.  It takes as its input generic commands and produces
an ASCII stream of data that will make the generic commands come out
right on the output device.

	The input structures permit creation of a large number of
contexts for parsing.  The context goes down to the file and window
level.  Initially, the X supported mechanisms of associating the
keyboard with a window will be used to determine context for typed and
moused input.  At some later time this facility may be changed.  What
this boils down to is that context is largely implied by what window
the mouse happens to be in.  Having a global context instead is
harder.

----
Screen presentation
File presentation
Process presentation

File input
Keyboard input
Mouse input - Unique to windows
Process input

Data
Commands
Context - imposed by parser and event handler

Keys 
Events - unique to windows
Parses

----

There should be extensive mouse and menu support.

There should be a status line that tells what clicking the mouse will
do in any particular context.  Although it would be a nice feature to
turn this off, it is not strictly necessary.

There should be a keyed command set as well as a menu command set.
There should be 7 +/-2 keys to memorize which give the user THE things
to know to find his way around in the system.  (The emacs ^H for help
is an excellent model.)

It should be possible to disable ANY user interface feature, mode or
capability, so that it can get out of the way of someone who does not
want it.

----

Menu mode  --> Menu text, hierarchy, bindings.
Key mode  --> Key Bindings
Long Command mode  --> command syntax

... and it all boils down to a C procedure with arguments...

Types of args

None
In-line
Parsed

Parser:
  outputs:
    string
    integer
    array
    C procedure pointer
  inputs from:  (non-exclusive bit mask)
    Mouse
    Menu
    Keyboard
    Munged buffer contents...

The menu commands and the key commands should expand visibly in the
long command window.

Long commands and key commands, if left un-completed for a long time
should pop up a menu of choices automatically.

----

Editor commands - first cut:
Base Parser

<Command> <Region Specifier> <Confirmation>

Confirmation can be enabled on all commands but in practice will be
applied only to commands of wide scope.

Need a way to specify conditions under which command will ask for
confirmation. 

At any time a command may be <Abort>'ed.

The Region specifier is the most difficult part to express.

Modifiers
  First
  Last
  Begining
  End
  <Number>
  <BIG>

Types
  One type for each named type of region
  Some regions are a Region structure
	Document
	Picture
  Some regions are delineated by search rules
	Word is text delimited by whitespace.
	Sentence is text begining with a capital letter and ending
	  with a period and whitespace.
  Some regions are BOTH!
  Some regions have an optional formatter directive:
	@chapter
	.BP

----

Command interpreter implementation

Multiple possible
  Key Bindings
  Mouse bindings
  Command parsers