\section{Benefits of our technique}
 
There are several advantages to our technique compared to other
existing solutions.

First, most techniques expose a more concrete representation of the
buffer to client code, such as a doubly linked list of lines.  Our
technique is defined in terms of an abstract \clos{} protocol that can
have several potential implementations.

Furthermore, our \emph{update protocol} based on time stamps provides
an elegant solution to the problem of updating multiple views at
different times and with different frequencies.  As opposed to the
technique of using \emph{observers} preferred in the object-oriented
literature \cite{Gamma:1998:DPC:551551}, time stamps require no
communication from the model to the views as a result of
modifications; indeed, such communication would be undesirable because
of the high frequency of modifications to the model compared to the
frequency of view updates.  Instead, view updates are at the
initiative of the views that need updating, and only when they need to
be updated.  The standard buffer implementation provided by our
library provides an efficient implementation of the update protocol.

Because of the way the line-editing protocol is designed, a line can
contain any \commonlisp{} object, and therefore any characters.  The
standard implementation of the line editing protocol uses simple
vectors%
\footnote{A simple vector is a \commonlisp{} one-dimensional array,
  capable of storing any \commonlisp{} object.}
to store the data.  But the standard implementation in no way
restricts the contents of a line to be characters.  Client code can
store any object in a line that it is prepared to receive when the
contents of a line is asked for.

Our technique can be \emph{customized} by the fact that the buffer
editing protocol and the line-editing protocol are independent.
Client code with specific needs can therefore replace the
implementation of one or the other or both according to its
requirements.  Thanks to the existence of the \clos{} protocol, such
customization can be done gradually, starting with the supplied
implementations and replacing them as requirements change.  A typical
customization might be to optimize the implementation of the
line-editing protocol so that when every object in a particular line
is an ASCII character, an efficient string representation is
used instead of a simple vector.

The standard line implementation supplied makes it possible to obtain
reasonable performance for aggregate editing operations even when
these operations are implemented as iterative calls to elementary
editing operations.  This quality makes it possible for client code to
be simpler, for obvious benefits.

A reasonable question that one might ask is whether the additional
abstraction layer in the form of generic functions will have a
negative impact on overall performance of an editor that uses our
technique, especially since the protocols allow for the buffer to
contain not only characters, but arbitrary objects.  One important
reason for designing these protocols was that we are convinced that
the performance bottleneck is not in the communication between the
buffer and the views, in particular given the design of the update
protocol.  Instead, the main performance challenge lies in how the
views organize the data supplied by our protocols and how they
interpret and display the data, and such design decisions are
independent of the buffer protocols.

Finally, our technique is not specific to the abstractions of any
particular existing editor, making our library useful in a variety of
potential clients.  In fact, we are already aware of one project for
using our library in order to create a VIM-like editor.
