Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
P
papers
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Model registry
Operate
Environments
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Terms and privacy
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
climacs
papers
Commits
30c8f162
Commit
30c8f162
authored
19 years ago
by
Christophe Rhodes
Browse files
Options
Downloads
Patches
Plain Diff
Minor revisions
parent
edf6f17a
No related branches found
Branches containing commit
No related tags found
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
climacssyntax.tex
+30
-30
30 additions, 30 deletions
climacssyntax.tex
with
30 additions
and
30 deletions
climacssyntax.tex
+
30
−
30
View file @
30c8f162
...
...
@@ -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: inclu
ding
directive:
the
inclu
sion 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
}
demonstrate
s 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
}
show
s 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 relati
ve
l
y
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 edito
r. 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
ve
r
y
competent and stable editor, especially
given the relatively small amount of work (only a few person-months)
that has been put into it so fa
r. 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
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment