Skip to content
Snippets Groups Projects
Commit 30c8f162 authored by Christophe Rhodes's avatar Christophe Rhodes
Browse files

Minor revisions

parent edf6f17a
No related branches found
No related tags found
No related merge requests found
......@@ -319,7 +319,7 @@ this additional complexity with no difficulty.
Another area of difficulty is the fact that parsing a Prolog text can
change the grammar itself through the use of the \texttt{op/3}
directive: including
directive: the inclusion of
\begin{verbatim}
:- op(100,xfy,<>).
\end{verbatim}
......@@ -422,15 +422,15 @@ tablature. In its simplest form, it is a sequence of
whitespace-delimited independent words, where each word represents
either a set of frets to depress and strings to be sounded, or
alternatively some element of musical notation (such as a barline);
figure \ref{fig:besfantlach} demonstrates a fragment of manuscript,
and its \TabCode\ encoding. It is also possible to encode more
complex elements of lute tablature notation in \TabCode: ornaments,
fingering marks, beaming, connecting lines and other complex elements
can all be accommodated (see figure \ref{fig:barley} for examples of
some of these more complex elements). \TabCode\ has been used to
produce scholarly editions of lute works \cite{Weiss} and to assist in
computer-based musicological studies (as in \cite{ecolm-graz} for
example).
figure \ref{fig:besfantlach} shows a fragment of manuscript, and
demonstrates its \TabCode\ encoding. It is also possible to encode
more complex elements of lute tablature notation in \TabCode:
ornaments, fingering marks, beaming, connecting lines and other
complex elements can all be accommodated (see figure \ref{fig:barley}
for examples of some of these more complex elements). \TabCode\ has
been used to produce scholarly editions of lute works \cite{Weiss} and
to assist in computer-based musicological studies (as in
\cite{ecolm-graz} for example).
The \TabCode\ language itself has developed to provide a terse and
intuitive encoding of tablature, rather than a well-formed grammar for
......@@ -444,7 +444,7 @@ each note, and can be parsed as such.
\begin{figure}
\begin{center}
\includegraphics{boardfig}
\caption{Extract from 'An Almand by mr Jo Dowland Bacheler of
\caption{Extract from `An Almand by mr Jo Dowland Bacheler of
musique', \textit{The Board Lute Book} (GB:Lam MS 603), f.13.
Note in particular the connecting lines in this bar, joining
chords within beams to an unbeamed chord.}
......@@ -502,17 +502,17 @@ revision and navigation.
\section{Future Work and Conclusions}
\label{sec:conclusions}
Given the relatively small amount of work (only a few person-months)
that has been put into Climacs so far, it is already a very competent
and stable editor. Using CLIM (and in particular the McCLIM
\cite{ilc2002-moore} implementation) as the display engine has allowed
the project to progress much more rapidly than would otherwise have
been possible. However, Climacs development has also revealed some
serious limitations and performance problems of the McCLIM library.
Nevertheless, we maintain that using CLIM and McCLIM was the best
choice, and in fact advantageous to other McCLIM users as well, as the
deficiencies in McCLIM implementation are being addressed and other
improvements made for use with Climacs.
Climacs is already a very competent and stable editor, especially
given the relatively small amount of work (only a few person-months)
that has been put into it so far. Using CLIM (and in particular the
McCLIM \cite{ilc2002-moore} implementation) as the display engine has
allowed the project to progress much more rapidly than would otherwise
have been possible. However, Climacs development has also revealed
some serious limitations and performance problems of the McCLIM
library. Nevertheless, we maintain that using CLIM and McCLIM was the
best choice, and in fact advantageous to other McCLIM users as well,
as the deficiencies in McCLIM implementation are being addressed and
other improvements made for use with Climacs.
Due to its reliance on fairly well-defined protocols, the Climacs text
editor framework is flexible enough to allow for different future
......@@ -527,20 +527,20 @@ exercise the Climacs protocols to a very high degree. This will allow
us to improve those protocols as well as their corresponding
implementations.
Another future direction high up on the list of priorities is the
planned implementation of the buffer protocol. Representing a line
being editied as a flexichain can greatly improve the performance of
some crucial operations that currently require looping over each
buffer object until a newline character is found. Other operations
that are currently prohibitive include knowing the line- and column
number of a given mark.
Another important future direction is the planned implementation of
the buffer protocol. Representing a line being edited as a flexichain
can greatly improve the performance of some crucial operations that
currently require looping over each buffer object until a newline
character is found. Other operations that are currently prohibitive
include knowing the line- and column number of a given mark.
One disadvantage of the current parsing scheme is that a single parse
error prevents analysis of the rest of the buffer, which is
potentially disturbing to a user's workflow. For relatively simple
grammars such as \TabCode, it is simple enough to resynchronize at the
next token, whereas for more complex grammars the resolution is less
clear.
clear. Providing a framework for customizeable resynchronising of the
parser after a parse error would allow for more user-friendly editing.
Our plans for Climacs go further than creating an improved
implementation of Emacs. We intend to make Climacs a fully-integrated
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment