\section{Introduction}
\label{sec-introduction}

Many applications and libraries contain a data structure for storing
and editing text.  In a simple input editor, the content can be a
single, relatively short, line of text, whereas in a complete text
editor, texts with thousands of lines must be supported.

In terms of abstract data types, one can think of an editor buffer as
an \emph{editable sequence}.  The problem of finding a good data
structure for such a data type is made more interesting because a data
structure with optimal asymptotic worst-case complexity would be
considered as having too much overhead, both in terms of execution
time, and in terms of memory requirements.

For a text editor with advanced features such as keyboard macros, it
is crucial to distinguish between two different control loops:

\begin{itemize}
\item The innermost loop consists of inserting and deleting individual
  items%
\footnote{In a typical editor buffer, the items it contains are
  individual characters.  Since our protocols and our implementations
  are not restricted to characters, we refer to the objects contained
  in it as ``items'' rather than characters.  An item is simply an
  object that occupies a single place in the editable sequence that
  the buffer defines.}
in the buffer, and of moving one or
  more \emph{cursors} from one position to an adjacent position.
\item The outer loop consists of updating the \emph{views} into the
  buffer.  Each view is typically an interval of less than a
  hundred lines of the buffer.
\end{itemize}

When the user inserts or deletes individual items, the inner loop
performs a single iteration for each iteration of the outer loop,
i.e., the views are updated for each elementary operation issued by
the user.

When operations on multiple items are issued, such as the insertion or
deletion of \emph{regions} of text, the inner loop can be executed a
large number of iterations for a single iteration of the outermost
loop.  While such multiple iterations could be avoided in the case of
regions by providing operations on intervals of items, doing so does
not solve the problem of \emph{keyboard macros} where a large number
of small editing operations can be issued for a single execution of a
macro.  Furthermore, to avoid large amounts of special-case code, it
is preferable that operations on regions be possible to implement as
repeated application of elementary editing operations.

Roughly speaking, we can say that each iteration of the outer loop is
performed for each character typed by the user.  Given the relatively
modest typing speed of even a very fast typist, as long as an
iteration can be accomplished in a few tens of milliseconds,
performance will be acceptable.  This is sufficient time to perform a
large number of fairly sophisticated operations.

An iteration of the inner loop, on the other hand, must be several
orders of magnitude faster than an iteration of the outer loop.

In this paper, we propose a data structure that has fairly low
overhead, both in terms of execution time and in terms of storage
requirements.  More importantly, our data structure is defined as a
collection of \clos{} \emph{protocols} each one aimed either at the
inner or the outer control loop.

In \refSec{sec-previous-work}, we provide an overview of existing
representations of editor buffers, along with the characteristics of
each representation.  We give examples of existing editors with
respect to which representation each one uses.

%%  LocalWords:  startup runtime
