\section{Conclusions and future work}

In this paper, we have defined a \clos{} protocol for manipulating
text editor buffers.  The protocol is divided into several
sub-protocols, so that sophisticated clients can provide specific
implementations according to the requirements of the application.

The \emph{update} sub-protocol was designed to be used by an arbitrary
number of \emph{views}.  The implementation we supply is fast so that
this protocol can be invoked for events such as keystrokes, exposures,
and changes of window geometry.

The features provided by \clos{} are invaluable for the design of
protocols like these.  These features allow for partial or total
customization of a large number of the details of the protocols while
still providing reasonable default design choices that are workable
for the majority of clients.

Our technique will have very little influence on the harder parts of
editor design, such as managing variable-size fonts and the mixture of
text and other objects to be displayed.  The objective of our
technique is more modest, namely to eliminate the necessity for
creators of editors to make decisions about the organization of the
buffer, and as a consequence also diminish the maintenance
requirements on the code for buffer management.

In the remainder of this section, we outline future plans for the
library.

\subsection{Layer for Emacs compatibility}

We plan to define a protocol layer on top of the edit protocols with
operations that have the same semantics as the buffer protocol of GNU
Emacs.  Mainly, this work involves hiding the existence of individual
lines, and treating the separation between lines as if it contained a
\emph{newline} character.

When a cursor is moved forward beyond the end of a line, or backward
beyond the beginning of a line, this compatibility layer will have to
detach the cursor from the line that it is currently attached to and
re-attach it to the following or preceding line as appropriate.

Other minor operations need to be adapted, such as computing the item
count of the entire buffer.  This calculation will have to consider
the separation of each pair of lines to contribute another item to the
item count of the buffer.

\subsection{Incremental \commonlisp{} parser}

One of the essential reasons for the present work is to serve as an
intermediate step towards the creation of a fully featured editor for
\commonlisp{} code, entirely written in \commonlisp{}.  Such an editor
must be able to analyze the buffer content at least at the same
frequency as that of the update of a view.

To that end, we plan to create a framework that allows the incremental
parsing of the buffer content as \commonlisp{} code.  Such a
framework should allow for features such as syntax highlighting and
automatic code indentation.  Preferably, it should have a fairly
accurate representation of the code such that the role of various code
fragments can be determined.  For example, it would be preferable to
distinguish between a symbol in the \texttt{common-lisp} package when
it is used to name a \commonlisp{} function and when (as the
\commonlisp{} standard allows) it is used as a lexical variable with
no relation to the standard function.

The first step of this incremental parser framework will be to adapt
an implementation of the \commonlisp{} \texttt{read} function so that
it can be used for incremental parsing, and so that the interpretation
of \emph{tokens} can take into account the specific situation of an
editor buffer.

To take into account the different roles of symbols, the framework
needs to include a \emph{code walker} so that the occurrence of macro
calls will not hamper the analysis.

\subsection{Thread safety}

The current implementation assumes that access is single-threaded.  We
plan to make multi-threaded access possible and safe.  Implementing
thread safety is not particularly difficult in itself.  The
interesting part would be to determine whether it is possible to
achieve multi-threaded access without using a global lock for the
entire buffer for every elementary operation.  Clearly some high-level
operations such as deleting a region that spans several lines may
require a global lock, since such an operation involves several
elementary operations involving both the buffer-level and the
line-level editing protocols.

Since each line is a separate object, it would appear that locking a
single line would be sufficient for most operations such as inserting
or deleting a single item.  However, the current implementation also
keeps the \emph{item count} of the entire buffer up to date for each
such operation.

Fortunately, the item count for the entire buffer is typically asked
for only at the frequency of the update protocol, for instance, in
order to display this information to the end user.  Other situations
exist when this information is needed, for example when an operation
to go to a particular item offset is issued.  But such operations are
relatively rare.

This analysis suggests that it may be possible to update the global
item count lazily.  Each line would be allowed to have a different
item count from what is currently stored in the buffer data structure,
and the buffer itself would maintain a set of lines with modified item
counts.  When the global item count of the buffer is needed, this set
is first processed so that the global item count is up to date.
