PROBLEM

To provide a helpful computerized writing environment, a comprehensive
and well interconnected set of composition tools must be developed.
The first few tools would consist of a doodler, outliner, composer,
editor, formatter, annotator, abstractor, and tutorials.  In the
doodler, the user would scribble into selectible sections of a screen
typing, line drawing, or other simple doodling functions.  The
outliner would help orgnized the doodles into a more sequential form
until a complete outline results.  The outline would be filled out
with text using the composer.  The emphasis would be on adding text
not refining it.  After the text were fleshed out, it would pass to
the editor for revision.  The revised text is formatted to look as it
would on paper.  Then marginal notes which would not appear in the
document could be associated with particular parts of the paper with
the use of the annotator.  For selecting special parts of the document
for other uses, the abstractor would be use.  The tutorials would work
along side the compositional tools to provide helps in such things as
writer's block and brainstorming. By integrating them into the
composition system, their output could be made to affect the final
form of the document being composed..

A special Athena Writing Testbed system should be written.  It will
provide a place to try out new ideas, a framework for building tools,
an environment for testing them, a repository for common modules of
use to other tools, and a common system to integrate the tools into.
No existing software system provides adequate functionality or
performance in these five areas.

The system must be modular, but above all, the system must have an
underlying structure that permits intimate interfacing between
component modules.  Not only will the user be able to run several
tools from within the system, the operation of the tools will be able
to affect text that is shared and modified by other tools in an
immediate, what you see is what you get (WSIWYG), fashion.  For
example: With an outline connected to a formatted document, moving
lines in the outliner would move paragraphs in the final form document
under view.

LIMITATIONS OF EMACS

Emacs started as editing macros written for the Text Editor and
COrrector program (TECO), and is now a stand alone editing system with
its own internal extension language.  Emacs has been in use for many
years, and the latest version seen by Athena, Gnuemacs has the
greatest performance and functionality of any version of Emacs.  MIT
students have had a lot of experience using Emacs.  As a testbed for
writing tools Emacs offers the following:

    High performance screen update and memory management
    A built in lisp interpreter and compiler for extensions
    The ability to monitor user keystrokes by spooling them to a file

Emacs is not sufficient for all the needs of the writing testbed.  It
is primarily an editor.  Any functions added on beyond editing will be
limited by the underlying architecture of the program.  Its monitoring
facilities for user input consist of a few simple hooks to pour the
keystrokes into a file.  Considerably more than that will be needed.

The Emacs command syntax consists of memorizing keystrokes that
perform functions.  It is hard for the new user to sort out the
functions and really learn them.  More experimentation is needed to
find command structures that are easy to learn and appply.  The Athena
Writing Testbed system will have to be so modularized to permit
changing the commands and command set that the user sees so that this
experimentation can occur.

Emacs is not well suited to integrated tools manipulating multiple
streams of text in highly interconnected ways.  The ability to edit
large blocks of text in different buffers is woefully inadequate.
What is needed is the ability to have many blocks of shared, derived,
and interconnected text.  If Emacs were applied in this way, it would
run too slowly to be useable.

SOLUTION -- FOUNDATION

Foundation is the name of a system for assembling Athena writing tools
in an erector-set-like fashion.  Component tools will be made as
independent as possible so that rewriting, replacing, or removing one
module will have minimal impact on the rest of the system.  It is not
clear which tools will end up being the most useful, or what sort of
user interface will be most comfortable.  Therefore Foundation is
designed to make it easy to try a lot of different approaches.
Frequent reviews of performance and functionality will drive evolution
of the system.

It will be possible to write several user interfaces and try them
out over time.  By careful monitoring of the system's usage we will
gain significant insight into what constitutes a good user interface
for writing tools.  Special consideration will be given to managing
the complexity the user sees and keeping the system from seeming
intimidating.

It is important to have explicit control over the conditions in which
change in one block of text affects another.  Sometimes it is useful
for a document to automatically be re-arranged when lines in an
outline are re-arranged.  Under other conditions, it is appropriate to
spin off a second copy of a document and then be able to compare the
effects of the changes.  Also, performance may become unacceptably
slow if an attempt is made to propagate too many sets of complicated
changes.

Structured storage of text together with a scheduling facility will
permit high performance implementations of very complicated sets of
tools.  These tools will be interfaced with the level of intimacy
described at the begining.

APPLICABILITY

Foundation will have wider applicability than just the MIT Writing
Program.  It can be used as a development testbed for new User
Interfaces.

Storage Allocator:

We now have  a modified version of the UNIX system calls for malloc,
realloc and free.  The versions we got were from Cal Tech and offered
greater speed.  We have added several debugging modes to enable
programmers to quickly find errors in their use of memory such as
going outside of expected bounds and using space that has been
de-allocated.

I/O:

We are developing the lext level of interface between a program and
the X window system.  We have applied knowledge of redisplay
algorithms and have come up with routines that may have general
applicability to anyone who is putting up rectangular regions of text
on a window.

Process Scheduling:

As was mentioned above, it is important to limit the amount of work
done as a consequence of propagating data and change instructions
among many interlocked blocks of text.  The queueing and scheduling,
and redundancy eliminating routines may find use in other large
subsystems.