\documentclass{beamer}
\usepackage[utf8]{inputenc}
\beamertemplateshadingbackground{red!10}{blue!10}
%\usepackage{fancybox}
\usepackage{epsfig}
\usepackage{verbatim}
\usepackage{url}
%\usepackage{graphics}
%\usepackage{xcolor}
\usepackage{fancybox}
\usepackage{moreverb}
%\usepackage[all]{xy}
\usepackage{listings}
\usepackage{filecontents}
\usepackage{graphicx}

\lstset{
  language=Lisp,
  basicstyle=\scriptsize\ttfamily,
  keywordstyle={},
  commentstyle={},
  stringstyle={}}

\def\inputfig#1{\input #1}
\def\inputeps#1{\includegraphics{#1}}
\def\inputtex#1{\input #1}

\inputtex{logos.tex}

%\definecolor{ORANGE}{named}{Orange}

\definecolor{GREEN}{rgb}{0,0.8,0}
\definecolor{YELLOW}{rgb}{1,1,0}
\definecolor{ORANGE}{rgb}{1,0.647,0}
\definecolor{PURPLE}{rgb}{0.627,0.126,0.941}
\definecolor{PURPLE}{named}{purple}
\definecolor{PINK}{rgb}{1,0.412,0.706}
\definecolor{WHEAT}{rgb}{1,0.8,0.6}
\definecolor{BLUE}{rgb}{0,0,1}
\definecolor{GRAY}{named}{gray}
\definecolor{CYAN}{named}{cyan}

\newcommand{\orchid}[1]{\textcolor{Orchid}{#1}}
\newcommand{\defun}[1]{\orchid{#1}}

\newcommand{\BROWN}[1]{\textcolor{BROWN}{#1}}
\newcommand{\RED}[1]{\textcolor{red}{#1}}
\newcommand{\YELLOW}[1]{\textcolor{YELLOW}{#1}}
\newcommand{\PINK}[1]{\textcolor{PINK}{#1}}
\newcommand{\WHEAT}[1]{\textcolor{wheat}{#1}}
\newcommand{\GREEN}[1]{\textcolor{GREEN}{#1}}
\newcommand{\PURPLE}[1]{\textcolor{PURPLE}{#1}}
\newcommand{\BLACK}[1]{\textcolor{black}{#1}}
\newcommand{\WHITE}[1]{\textcolor{WHITE}{#1}}
\newcommand{\MAGENTA}[1]{\textcolor{MAGENTA}{#1}}
\newcommand{\ORANGE}[1]{\textcolor{ORANGE}{#1}}
\newcommand{\BLUE}[1]{\textcolor{BLUE}{#1}}
\newcommand{\GRAY}[1]{\textcolor{gray}{#1}}
\newcommand{\CYAN}[1]{\textcolor{cyan }{#1}}

\newcommand{\reference}[2]{\textcolor{PINK}{[#1~#2]}}
%\newcommand{\vect}[1]{\stackrel{\rightarrow}{#1}}

% Use some nice templates
\beamertemplatetransparentcovereddynamic

\newcommand{\A}{{\mathbb A}}
\newcommand{\degr}{\mathrm{deg}}

\title{A CLOS Protocol for Editor Buffers}

\author{Robert Strandh}
\institute{
LaBRI, University of Bordeaux
}
\date{May, 2016}

%\inputtex{macros.tex}


\begin{document}
\frame{
\resizebox{3cm}{!}{\includegraphics{Logobx.pdf}}
\hfill
\resizebox{1.5cm}{!}{\includegraphics{labri-logo.pdf}}
\titlepage
\vfill
\small{European Lisp Symposium, Cracow, Poland \hfill ELS2016}
}

\setbeamertemplate{footline}{
\vspace{-1em}
\hspace*{1ex}{~} \GRAY{\insertframenumber/\inserttotalframenumber}
}

\frame{
\frametitle{An editor buffer as an \emph{editable sequence}}

\begin{itemize}
\item An editor buffer can be considered to be an \emph{editable
  sequence} of items.
\item Solutions with optimal asymptotically worst-case complexity are
  too slow and/or have too much space overhead.
\item We must take advantage of typical use cases to do better.
\item Two main representations:
  \begin{enumerate}
  \item Gap buffer.
  \item Line oriented.
  \end{enumerate}
\end{itemize}
}

\frame{
  \frametitle{Gap buffer}

  \begin{itemize}
  \item The contents of the buffer is stored in a \emph{vector}.
  \item Three parts:
    \begin{enumerate}
    \item A possibly empty \emph{prefix} of items.
    \item A possibly empty \emph{gap}.
    \item A possibly empty \emph{suffix} of items.
    \end{enumerate}
  \item Items are moved so that modifications are either at the
    beginning or at the end of the gap.
  \end{itemize}

}

\frame{
  \frametitle{Line oriented}

  \begin{itemize}
  \item Representation as a two-level editable sequence.
  \item The outer level is a sequence of lines.
  \item At the inner level, each line is a sequence of items.
  \item The outer level can be a gap buffer, but can also use
    a traditional representation such as a tree.
  \end{itemize}
}

\frame{
  \frametitle{Existing editors}

  \begin{itemize}
  \item GNU Emacs and (first) Climacs use a gap buffer to represent
    the entire editor buffer.
  \item Many others use a doubly linked list of lines, such as Multics
    Emacs, Hemlock, Goatee.
  \item VIM uses a tree of file-backed blocks.
  \end{itemize}
}

\frame{
  \frametitle{Frequency of operations}

Two loops:

  \begin{itemize}
  \item The slow loop.  It is typically triggered by a keystroke, but
    can also be triggered by other events such as mouse events or when
    a window is re-sized.
  \item The fast loop.  Each iteration is an operation to
    insert/delete an item, or to move a cursor.
  \end{itemize}
}

\frame{
  \frametitle{The slow loop}

  \begin{itemize}
  \item Sufficiently slow that the entire view can be redrawn for each
    iteration.
  \item The view must determine what has changed in the buffer since 
    it was last redrawn. 
  \end{itemize}
}

\frame{
  \frametitle{The fast loop}

  \begin{itemize}
  \item The fast loop is faster because a single keystroke can trigger
    several operations, for example when a region is inserted/deleted,
    or when a keyboard macro is executed.
  \item Some fast cases could be avoided by the use of special
    operations on regions.
  \item With keyboard macros, multiple operations can not easily be
    avoided.
  \item Besides, for reasons of maintainability, it is best to avoid
    special cases.
  \end{itemize}
}

\frame{
  \frametitle{Two protocols}

  \begin{itemize}
  \item The \emph{edit} protocol corresponding to the fast loop.
  \item The \emph{update} protocol corresponding to the slow loop.
  \end{itemize}
}

\frame{
  \frametitle{Edit protocol}

Divided into two sub-protocols

\begin{enumerate}
\item The \emph{line-edit} protocol.
\item The \emph{buffer-edit} protocol.
\end{enumerate}

The two sub-protocols can be independently customized.
}

\frame{
  \frametitle{Line-edit protocol}

Defines two classes:

\begin{enumerate}
\item \texttt{line}
\item \texttt{cursor}
\end{enumerate}

Defines several generic functions:

\begin{itemize}
\item Inserting and deleting items.
\item Querying item count.
\item Moving cursors.
\item Attaching and detaching cursors.
\end{itemize}

}

\frame{
  \frametitle{Buffer-edit protocol}

Defines the class \texttt{buffer}.
\vskip 1cm
Defines several generic functions:

\begin{itemize}
\item Splitting and joining lines.
\item Querying line count and item count.
\end{itemize}

}

\frame{
  \frametitle{Update protocol}

\begin{itemize}
\item Defines a single generic function named \texttt{update}.
\item Modifications to the buffer are marked with a \emph{time stamp}.
\item A view passes the time stamp of the previous call to \texttt{update}.
\end{itemize}

}

\frame{
  \frametitle{The \texttt{update} function}

Has six parameters: The buffer, the time stamp of the previous update,
and four function parameters defining edit operations on the view.
\vskip 0.3cm
The view maintains a sequence of lines and an index into the sequence.
The function parameters operate on this sequence and on the index:

\begin{itemize}
\item \texttt{skip} takes a single argument, an integer to add to the
  index.
\item \texttt{modify} takes a single argument, the next line that has
  been modified.  The view deletes lines until the modified line has
  been found.
\item \texttt{insert} takes a single line, the line that has been
  inserted.  The view inserts the line.
\item \texttt{sync} takes a single argument, the next line that has
  not been modified.  The view deletes lines until the line has been
  found.
\end{itemize}

}

\frame{
  \frametitle{Standard implementation}

  \begin{itemize}
  \item A buffer is represented as a splay tree of lines.
  \item A line is either \emph{open} or \emph{closed} depending on the
    last operation on it:
    \begin{itemize}
    \item An open line is represented as a gap buffer.
    \item A closed line is represented as a simple vector.
    \end{itemize}
  \end{itemize}
}

\frame{
  \frametitle{Benefits of our technique}
}

\frame{
  \frametitle{Simplicity of editing operations}

The consequences of the separation of the edit and the update
protocols are that complex operations (regions, keyboard macros) can
be implemented as a number of simpler operations without hampering
performance.

}

\frame{
  \frametitle{Customization}

The benefits of using generic functions:

\begin{itemize}
\item Behavior can be customized with auxiliary methods.
\item Sophisticated users with special requirements can supply their
  own implementations of the line-edit and buffer-edit protocols.
\item A number of operations are implemented as combinations of
  simpler operations.  This behavior can be overridden.
\end{itemize}

}

\frame{
  \frametitle{Views are updated only when needed}

Thanks to the update protocol based on time stamps, there is no
communication from the model (i.e., the buffer) to the views.
\vskip 0.3cm
As a result, a view is updated only when needed, and not, for
instance, when it is hidden.
}

\frame{
  \frametitle{Future work}
}

\frame{
  \frametitle{Emacs compatibility layer}

  \begin{itemize}
  \item In an Emacs buffer, a newline character is just another
    character. 
  \item Moving a cursor across a newline character involves detaching
    and attaching the cursor.
  \item Inserting a newline character involves splitting a line.
  \item Deleting a newline character involves joining two lines.
  \end{itemize}
}

\frame{
  \frametitle{Incremental Common Lisp parser}

  \begin{itemize}
  \item Based on a special version of the \texttt{read} function.
  \item It is special in that tokens are interpreted differently.
  \end{itemize}
}

\frame{
  \frametitle{Thread safety}

  \begin{itemize}
  \item Avoid locking the entire buffer for operations confided to a
    single line.
  \item Complication: The buffer maintains a global item count.
  \item Handle global item count by updating only when needed.
  \end{itemize}

}

\frame{
  \frametitle{Acknowledgments}

We would like to thank Daniel Kochmański, Bart Botta, and Matthew Alan
Martin for providing valuable feedback on early versions of this
paper.
}

\frame{
\frametitle{Thank you}

Questions?
}

%% \frame{\tableofcontents}
%% \bibliography{references}
%% \bibliographystyle{alpha}

\end{document}
