climacs-cvs

climacs-cvs@common-lisp.net

847 discussions

[climacs-cvs] CVS update: papers/ilc2005/syntax/climacssyntax.tex
by rstrandh＠common-lisp.net 23 May '05

23 May '05

Update of /project/climacs/cvsroot/papers/ilc2005/syntax In directory common-lisp.net:/tmp/cvs-serv12718 Modified Files: climacssyntax.tex Log Message: Corrected some statements about the current implementation that were incorrect. Added conclusions and future work. Date: Mon May 23 06:06:40 2005 Author: rstrandh Index: papers/ilc2005/syntax/climacssyntax.tex diff -u papers/ilc2005/syntax/climacssyntax.tex:1.14 papers/ilc2005/syntax/climacssyntax.tex:1.15 --- papers/ilc2005/syntax/climacssyntax.tex:1.14 Mon May 23 03:05:55 2005 +++ papers/ilc2005/syntax/climacssyntax.tex Mon May 23 06:06:39 2005 @@ -42,7 +42,7 @@ The Climacs text editor is a CLIM implementation of a text editor in the Emacs tradition. Climacs was designed to allow for incremental parsing of the buffer contents, so that a sophisticated analysis of - the buffer contents can be performed without impacting performance. + the contents can be performed without impacting performance. We describe two different syntax modules: a module for a sequentially-defined syntax of a typical programming language, doing the bulk of its parsing in a per-window function; and an interactive @@ -103,20 +103,21 @@ correctly, other expressions can still match on the contents of the comment, leading to issues when the first character in a column in the block comment is the start of a definition. Emacs users quickly learn -to insert a space before the open paren to work around Emacs' +to insert a space before the open parenthesis to work around Emacs' font-lock deficiencies. The Climacs text editor is a combination of frameworks for buffer representation and parsing, loosely coupled with a CLIM-based display engine. It includes the Flexichain library \cite{flexichain}, which provides an editable sequence representation and mark (cursor) -management using a simple linked lists used for implementing the -buffer protocol; and an implementation of a slight modification of the -Earley parsing algorithm \cite{earley}, to assist in the creation of -syntax-aware editing modes. An application can combine a particular -implementation of the buffer protocol, the syntax protocol, and its -own display methods to produce a sophisticated editor for a particular -language. +management using a simple linked list for implementing the buffer +protocol. Climacs also includes an implementation of a slight +modification of the Earley parsing algorithm \cite{earley}, to assist +in the creation of syntax-aware editing modes, though such modes can +use any appropriate parsing algorithm. An application can combine a +particular implementation of the buffer protocol, the syntax protocol, +and its own display methods to produce a sophisticated editor for a +particular language. The Climacs buffer protocol, which provides a standard interface to common text editor buffer operations, uses the Flexichain library; we @@ -125,7 +126,7 @@ provides a method for interfacing a lexical analyzer and parser with the text editor, and provides for defining methods to draw syntax objects in the Climacs window. In section \ref{sec:syntaxes} we -discuss the implementation of syntactic analysis for various +discuss the implementation of syntactic analyses for various programming languages, including Common Lisp; in section \ref{sec:tabeditor}, we discuss an application with Climacs at its core to support editing a textual representation of lute tablature. @@ -257,6 +258,36 @@ approach is appropriate when the parse tree will also be used for some other display or analysis of the text in the buffer. +Climacs includes a parser that uses the Earley \cite{earley} parsing +algorithm. There are many advantages of this algorithm in the context +of text editing. Perhaps most importantly, it does not require any +preprocessing of the grammar, which makes it necessary for the entire +grammar to be known ahead of time. This means that the user can +load Lisp files containing additional syntax rules to complete the +existing ones without having to apply any costly grammar analysis. +Other advantages include the possibility of using ambiguous grammars, +since the Earley parsing algorithm accepts the full class of +context-free grammars. This feature is crucial in certain +applications, for instance in a grammar checker for natural +languages. The Climacs syntax protocol can, but is not required +to, use the provided Earley parser. It can use any algorithm with an +explicit representation of the parser state, which is a necessary, but +not sufficient, requirement for making the parsing algorithm +incremental. + +However, the Earley parsing algorithm is relatively slow compared to +table-based algorithms such as the LR shift/reduce algorithm. +Worst-case complexity is $O(n^3)$ where $n$ is the size of the input. +It drops to $O(n^2)$ for unambiguous grammars and to $O(n)$ for a +large class of grammars suitable for parsing programming langauges. +Even so, the complexity is often proportional to the size of the +grammar (which is considered a constant by Earley), which can be +problematic in a text editor. We have yet to determine whether the +implementation of the Earley algorithm that we provide will turn out +to be sufficiently fast for most Climacs syntax modules. Other +possibilities include the Tomita parsing algorithm which provides more +generality than LR, but which is nearly as fast in most cases. + \section{Syntaxes} \label{sec:syntaxes} @@ -428,8 +459,55 @@ \section{Future Work and Conclusions} \label{sec:conclusions} -I like Jello. Jello is good. We should enable people to make better -Jello. +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 +implementation) as the display engine has allowed the project to +progress much more rapidly than what would have been possible +otherwise. However, Climacs has also revealed some serious +limitations and performance problems of the McCLIM library. We +maintain that using CLIM and McCLIM was the best choice, and in fact +advantageous to other McCLIM users as well, since work is being done +to correct and improve it 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 +directions. Turning the Common Lisp syntax module into an excellent +programming tool for Lisp programmers is high on the list of +priorities, for many reasons. First, it will encourage further work +on Climacs. Second, the Common Lisp syntax module is likely to become +one of the more advanced ones to exist for Climacs, given that Climacs +has unique and direct access to the features of the underlying Common +Lisp implementation. Thus, the Common Lisp syntax module is likely to +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 priorites 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. + +However, our plans for Climacs go further than creating an improved +implementation of Emacs. We intend to make Climacs a fully-integrated +CLIM application. This implies among other things using the +presentation-type system of CLIM to exchange objects between Climacs +and other CLIM appliations such as an inspector application, a +debugger pane, etc. We also hope that implementors of other CLIM +applications such as mail readers, news readers, etc, will consider +using Climacs for creating messages. + +We are often asked whether applications such as VM and Gnus for GNU +Emacs will be available for Climacs. Our opinion is that such +applications currenltly run as GNU Emacs subsystems, simply because +GNU Emacs does not have an independent substrate such as CLIM for +creating user interfaces. Climacs is itself a CLIM application, and +applications such as mail readers and news readers that do not require +editable buffers should instead be implemented directly as CLIM +applications, perhaps calling Climacs to write messages. \nocite{*}

1 0

[climacs-cvs] CVS update: papers/ilc2005/syntax/parserclasses.eps papers/ilc2005/syntax/parserclasses.pdf papers/ilc2005/syntax/ttcn3msc.eps papers/ilc2005/syntax/ttcn3msc.pdf papers/ilc2005/syntax/climacssyntax.tex
by bmastenbrook＠common-lisp.net 23 May '05

23 May '05

Update of /project/climacs/cvsroot/papers/ilc2005/syntax In directory common-lisp.net:/tmp/cvs-serv1803 Modified Files: climacssyntax.tex Added Files: parserclasses.eps parserclasses.pdf ttcn3msc.eps ttcn3msc.pdf Log Message: Buffer protocol description; some syntax Date: Mon May 23 03:05:55 2005 Author: bmastenbrook Index: papers/ilc2005/syntax/climacssyntax.tex diff -u papers/ilc2005/syntax/climacssyntax.tex:1.13 papers/ilc2005/syntax/climacssyntax.tex:1.14 --- papers/ilc2005/syntax/climacssyntax.tex:1.13 Sun May 22 13:47:26 2005 +++ papers/ilc2005/syntax/climacssyntax.tex Mon May 23 03:05:55 2005 @@ -58,42 +58,65 @@ \section{Introduction} The field of advanced text editors is a crowded one, with a long -history and an apparent ability to cause passionate argument. Climacs is philosophically part of the Emacs editor tradition, which has spawned many variants with many different approaches to buffer management, incremental redisplay, and syntax analysis. Emacs itself traces its lineage to TECO, where Emacs was originally implemented as a set of TECO macros. Climacs is compared to several interesting variants of Emacs in Table \ref{table:editorcompare}. +history and an apparent ability to cause passionate argument. Climacs +is philosophically part of the Emacs editor tradition, which has +spawned many variants with many different approaches to buffer +management, incremental redisplay, and syntax analysis. Emacs itself +traces its lineage to TECO, where Emacs was originally implemented as +a set of TECO macros. Climacs is compared to several interesting +variants of Emacs in Table \ref{table:editorcompare}. -\begin{figure*} \begin{center} +\begin{figure*} +\begin{center} \begin{tabular}{|c|c|c|c|c|} \hline \textbf{Editor} & \textbf{Buffer Implementation} & \textbf{Syntax Analysis} & \textbf{Language} \\ -\hline TECO & Gap Buffer & Unknown & Assembly + TECO Macros +\hline TECO & Gap buffer & Unknown & Assembly + TECO Macros \\ \hline Zmacs & Probably doubly-linked list of lines & None & MacLisp \\ -\hline GNU Emacs & Gap Buffer & Regular Expressions & C + Emacs Lisp +\hline GNU Emacs & Gap buffer & Regular Expressions & C + Emacs Lisp \\ \hline Hemlock & Doubly-linked list of lines & None & Common Lisp \\ -\hline FRED & Gap Buffer & None & PPC Assembly + Common Lisp +\hline FRED & Gap buffer & None & PPC Assembly + Common Lisp \\ \hline Deuce & Doubly-linked lists of lines & Unknown & Dylan \\ \hline Climacs & Multiple & Multiple & Common Lisp \\\hline \end{tabular} -\caption{Implementation strategies of multiple Emacs variants} \end{center} \label{table:editorcompare} \end{figure*} - -Climacs' syntax analysis is a flexible protocol which can be implemented with a full language lexer and parser. GNU Emacs, the most commonly used Emacs-like editor, uses regular expressions for its syntax analysis. Because these regular expressions are applied lazily and not on the whole buffer, constructs such as Common Lisp's nestable \verb+#| |#+ block comments will often confuse the regular expressions. If the parser starts after the opening \verb+#|+ then the closing \verb+|#+ will be treated as the start of an escaped symbol name. Even if the regular expression parses the whole block comment correctly, other expressions can still match on the contents of the comment, leading to issues when the first character in a column in the block comment is the start of a definition. Emacs users quickly learn to insert a space before the open paren to work around Emacs' font-lock deficiencies. +\caption{Implementation strategies of multiple Emacs variants} +\end{center} +\label{table:editorcompare} +\end{figure*} + +Climacs' syntax analysis is a flexible protocol which can be +implemented with a full language lexer and parser. GNU Emacs, the most +commonly used Emacs-like editor, uses regular expressions for its +syntax analysis. Because these regular expressions are applied lazily +and not on the whole buffer, constructs such as Common Lisp's nestable +\verb+#| |#+ block comments will often confuse the regular +expressions. If the parser starts after the opening \verb+#|+ then the +closing \verb+|#+ will be treated as the start of an escaped symbol +name. Even if the regular expression parses the whole block comment +correctly, other expressions can still match on the contents of the +comment, leading to issues when the first character in a column in the +block comment is the start of a definition. Emacs users quickly learn +to insert a space before the open paren to work around Emacs' +font-lock deficiencies. The Climacs text editor is a combination of frameworks for buffer representation and parsing, loosely coupled with a CLIM-based display engine. It includes the Flexichain library \cite{flexichain}, which provides an editable sequence representation and mark (cursor) management using a simple linked lists used for implementing the -buffer protocol; and an implementation of a -slight modification of the Earley parsing algorithm \cite{earley}, to -assist in the creation of syntax-aware editing modes. An application -can combine a particular implementation of the buffer protocol, the -syntax protocol, and its own display methods to produce a -sophisticated editor for a particular language. +buffer protocol; and an implementation of a slight modification of the +Earley parsing algorithm \cite{earley}, to assist in the creation of +syntax-aware editing modes. An application can combine a particular +implementation of the buffer protocol, the syntax protocol, and its +own display methods to produce a sophisticated editor for a particular +language. The Climacs buffer protocol, which provides a standard interface to common text editor buffer operations, uses the Flexichain library; we @@ -112,39 +135,119 @@ \section{Buffer Protocol} \label{sec:buffer} -The buffer protocol provides a set of methods for modifying and -reading the contents of a buffer which can contain arbitrary objects. -Typically these objects are characters, but the buffer can contain any -object that the syntax protocol can display in the Climacs window. The -buffer protocol is independent of any implementation of the protocol, -which allows flexible representations of buffers. - -The aim is for Climacs to provide several implementations of the -buffer protocol, one of which will use a sequence of lines organized -into a tree for quick access. In this implementation, a line can be -considered opened or closed. Editing operations are performed on -opened lines, which are represented as a cursorchain (a Flexichain -with an arbitrary number of cursors). A fixed number of lines are kept -opened according to a LRU scheme. When a line is closed it is -converted to a vector. If the line contains only base-char objects -this vector is a base-string; otherwise, it is unspecialized. -Currently, however, Climacs uses a single cursorchain for the entire -buffer, in effect making it a simple gap-buffer implementation. - -``Protocol'' is not just an empty claim, as there are already multiple -buffer implementations: Aleksandar Bakic's persistent buffer -implementations, providing a cheap implementation of the undo protocol. -(FIXME: a citation, either to something ``in preparation'' or to some -previous description of the ideas?) +Climacs abstracts the implementation of editable sequences as editor +buffers using the buffer protocol. The buffer protocol provides a set +of methods for modifying and reading the contents of a buffer, and +setting and retrieving marks in the buffer. Buffers can contain +arbitrary objects. Typically these objects are characters, but the +buffer can contain any object that the syntax protocol can display in +the Climacs window. The buffer protocol is independent of any +implementation of the protocol, which allows flexible representations +of buffers. + +Currently Climacs uses a single Flexichain ``cursorchain'' as the +editable sequence representation for standard buffers. A cursorchain +is a circular gap buffer with an arbitrary number of cursors in the +buffer. Climacs uses these cursors as the implementation of marks in +the buffer. The single gap-buffer implementation is used by many other +editors, including GNU Emacs. Flexichain improves on this by making +the gap buffer circular in its underlying representation; the start of +the sequence is stored in a separate slot, along with the beginning of +the gap. + +Climacs also provides a buffer implementation utilizing functional +data structures as the editable sequence representation. This buffer +implementation provides a low-cost implementation of undo along +multiple edit histories. (FIXME: a citation, either to something ``in +preparation'' or to some previous description of the ideas? It would +help if someone with more understanding than I of this buffer +implementation would sketch this out.) + +Climacs is intended to provide other buffer implementations, one of +which will use a sequence of lines organized into a tree for quick +access. In this structure, a line can be considered opened or +closed. When a line is opened, it is represented as a Flexichain +cursorchain. All editing operations are performed on open lines. A +fixed number of lines are kept opened according to a +least-recently-used scheme. When a line is closed it is converted to a +vector for efficient storage and access. If the line contains only +base-char objects this vector is a base-string; otherwise, it is +unspecialized. + +This structure has the advantage of efficient line-based access in the +buffer. It also provides much less pessimistic behavior than that of a +single gap buffer when a user is editing two disparate sections in a +large file. With a single gap buffer, the gap must be moved to the +point of edit before an edit operation is allowed. When the buffer is +large and edit operations occur frequently at multiple locations in +the buffer, this requires a substantial amount of copying between +edits. In this situation single-gap-buffer editors like Emacs will +noticably pause between edits to move the gap. A structure which +contains a sequence of lines and keeps the most recently used lines +open as gap buffers can operate as a multi-gap buffer with automatic +gap placement, while not providing pessimistic performance when +accessing a specific line in the buffer. + +The efficiency of Climacs buffers depends greatly on the +implementation of the buffer protocol that is used. Space efficiency +will also depend on the implementation of Common Lisp which is used to +run Climacs. In Steel Bank Common Lisp, the type character is +represented with the full 22 bits used by the Unicode character +space. External character encodings other than Unicode are converted +to Unicode when a file is read in to memory. If the characters are +stored in a specialized array, this will net a worst case space +efficiency of four bytes of every byte in the file. However, the time +advantages of this representation outweigh the space +inefficiency. Searching for an individual character in a sequence of +characters encoded in UTF-8 is $O(n)$, because each individual +character must be examined to determine the number of octets which are +stored to represent that character. + +The Flexichain library uses an unspecialized vector for its storage, +which uses one machine word per element, either as an immediate value +or as a pointer to a larger element. Climacs buffers can contain any +object, so in a suitably complex syntax and buffer protocol +implementation an object in a buffer may \section{Syntax Protocol} \label{sec:syntax} -A syntax in Climacs is an incremental parser which creates and updates -a parse tree of a buffer's contents, and provides a mechanism for -drawing these parsed objects in a window. The parser accepts lexemes -produced by an incremental lexical analyzer associated with the -syntax. +\begin{figure*} + \begin{center} + \includegraphics{parserclasses} + \caption{Organization of classes used by a typical syntax} + \label{fig:syntaxclasses} + \end{center} +\end{figure*} + +Climacs is designed to allow multiple implementation strategies for +buffer parsers and syntax-aware display mechanisms. The set of hooks +that Climacs provides to allow this is the syntax protocol. A syntax +in Climacs is a class and set of methods which provide a lexical +analyzer, parser, and display methods for a buffer. The incremental +parser associated with a syntax creates and updates a parse tree of a +buffer's contents, and provides a mechanism for drawing these parsed +objects in a window. The parser accepts lexemes produced by an +incremental lexical analyzer. Display is handled by drawing methods +implemented using the CLIM high-level display toolkit. + +Though a syntax is free to choose its own implementation strategy, +lexical analysis and parsing of the buffer is typically done in an +object-oriented fashion. The lexer operates on objects in the buffer, +usually characters, and returns objects of various classes. Each +parser production is represented by a class. In complex syntaxes, the +parser rules can be quite complicated and involve arbitrary code, but +for a simple grammar the parsing rules can be entirely represented by +matching on the classes returned by the tokenizer and parser. Figure +\ref{fig:syntaxclasses} shows the organization of classes in the TTCN3 +grammar. + +Climacs provides an Earley parser \cite{earley} which is sufficient to +parse most context-free grammars. Earley parser: discussion of +generality and asymptotic efficiency (in general and for usual cases). +Possibility of replacement in case of complicated grammars? (What was +that parsing algorithm that someone mentioned on \verb+#lisp+? +\textit{I have no idea.}) The syntax analysis can be applied either in a per-window or per-buffer function. The per-window approach is best suited to @@ -154,11 +257,6 @@ approach is appropriate when the parse tree will also be used for some other display or analysis of the text in the buffer. -Earley parser: discussion of generality and asymptotic efficiency (in -general and for usual cases). Possibility of replacement in case of -complicated grammars? (What was that parsing algorithm that someone -mentioned on \verb+#lisp+?) - \section{Syntaxes} \label{sec:syntaxes} @@ -186,7 +284,7 @@ Christophe might want to describe the Prolog syntax a bit here. In particular any details having to do with the implementation of operator precedence as specified in the ISO Prolog standard might be -interesting. +interesting. [ Maybe just the \textit{priority} stuff? I think that's the only interesting bit of non-context-freeness; user-defined @@ -209,6 +307,12 @@ slightly-buggy or incomplete syntax mode will render the whole thing useless. Violation of WiB? +The Testing and Test Control Notation 3 (TTCN3) language is a language +which captures detailed test specifications. TTCN provides both a +textual ``core'' grammar and a graphical presentation format similar +to Message Sequence Charts (see figure \ref{fig:ttcn3gr}). Climacs +currently provides an editor for a subset of the TTCN3 core language. + The TTCN3 syntax is implemented with a high-level macro which defines classes and adds syntax rules using the syntax protocol for each terminal and non-terminal in the grammar. The syntax of this macro @@ -218,6 +322,20 @@ receive their own non-terminal entry in the grammar. In addition, this macro defines basic display functions for the syntax objects produced by the parser, with language keywords appearing in a separate color. + +\begin{figure*} + \begin{center} + \parbox{0.45\linewidth}{\includegraphics{ttcn3msc}} + \parbox{0.25\linewidth}{\texttt{\\ [1cm]\noindent + testcase MyTestCase (inout integer MyPar)\\ + runs on MyMTCtype system SystemType \{\\ + var integer MyVar := 1;\\ + MyMTCPort.send(MyTemplate);\\ + \}}} + \caption{A fragment of TTCN3 and its corresponding Graphical Representation (GR)} + \label{fig:ttcn3gr} + \end{center} +\end{figure*} \subsection{Per-Buffer Syntax: a tablature editor} \label{sec:tabeditor}

1 0

[climacs-cvs] CVS update: climacs/ttcn3-syntax.lisp climacs/climacs.asd
by bmastenbrook＠common-lisp.net 23 May '05

23 May '05

Update of /project/climacs/cvsroot/climacs In directory common-lisp.net:/tmp/cvs-serv1250 Modified Files: climacs.asd Added Files: ttcn3-syntax.lisp Log Message: Add the TTCN3 syntax Date: Mon May 23 03:00:24 2005 Author: bmastenbrook Index: climacs/climacs.asd diff -u climacs/climacs.asd:1.28 climacs/climacs.asd:1.29 --- climacs/climacs.asd:1.28 Fri Apr 22 10:18:26 2005 +++ climacs/climacs.asd Mon May 23 03:00:24 2005 @@ -64,6 +64,7 @@ "cl-syntax" "html-syntax" "prolog-syntax" + "ttcn3-syntax" "gui" ;;---- optional ---- "testing/rt"

1 0

[climacs-cvs] CVS update: papers/ilc2005/syntax/climacssyntax.tex
by abakic＠common-lisp.net 22 May '05

22 May '05

Update of /project/climacs/cvsroot/papers/ilc2005/syntax In directory common-lisp.net:/tmp/cvs-serv19050 Modified Files: climacssyntax.tex Log Message: Minor fixes. I'll try to add some background/references soon. Date: Sun May 22 13:47:26 2005 Author: abakic Index: papers/ilc2005/syntax/climacssyntax.tex diff -u papers/ilc2005/syntax/climacssyntax.tex:1.12 papers/ilc2005/syntax/climacssyntax.tex:1.13 --- papers/ilc2005/syntax/climacssyntax.tex:1.12 Sun May 22 12:53:59 2005 +++ papers/ilc2005/syntax/climacssyntax.tex Sun May 22 13:47:26 2005 @@ -132,8 +132,8 @@ buffer, in effect making it a simple gap-buffer implementation. ``Protocol'' is not just an empty claim, as there are already multiple -buffer implementations: Aleksandr Bakic's persistent buffer -implementation, providing a cheap implementation of the undo protocol. +buffer implementations: Aleksandar Bakic's persistent buffer +implementations, providing a cheap implementation of the undo protocol. (FIXME: a citation, either to something ``in preparation'' or to some previous description of the ideas?)

1 0

[climacs-cvs] CVS update: papers/ilc2005/syntax/climacssyntax.tex
by rstrandh＠common-lisp.net 22 May '05

22 May '05

Update of /project/climacs/cvsroot/papers/ilc2005/syntax In directory common-lisp.net:/tmp/cvs-serv15544 Modified Files: climacssyntax.tex Log Message: Made the description of the current buffer protocol implementation more accurate. Date: Sun May 22 12:53:59 2005 Author: rstrandh Index: papers/ilc2005/syntax/climacssyntax.tex diff -u papers/ilc2005/syntax/climacssyntax.tex:1.11 papers/ilc2005/syntax/climacssyntax.tex:1.12 --- papers/ilc2005/syntax/climacssyntax.tex:1.11 Sat May 21 22:14:00 2005 +++ papers/ilc2005/syntax/climacssyntax.tex Sun May 22 12:53:59 2005 @@ -23,8 +23,8 @@ \affaddr{London SE14 6NW, UK}\\ \email{c.rhodes(a)gold.ac.uk} \alignauthor Robert Strandh\\ - \affaddr{Equipe Image et son, LaBRI}\\ - \affaddr{Domaine Universitaire}\\ + \affaddr{LaBRI}\\ + \affaddr{Universit\'{e} Bordeaux 1}\\ \affaddr{351, cours de la Lib\'{e}ration}\\ \affaddr{33405 Talence Cedex} \affaddr{FRANCE}\\ @@ -84,12 +84,16 @@ Climacs' syntax analysis is a flexible protocol which can be implemented with a full language lexer and parser. GNU Emacs, the most commonly used Emacs-like editor, uses regular expressions for its syntax analysis. Because these regular expressions are applied lazily and not on the whole buffer, constructs such as Common Lisp's nestable \verb+#| |#+ block comments will often confuse the regular expressions. If the parser starts after the opening \verb+#|+ then the closing \verb+|#+ will be treated as the start of an escaped symbol name. Even if the regular expression parses the whole block comment correctly, other expressions can still match on the contents of the comment, leading to issues when the first character in a column in the block comment is the start of a definition. Emacs users quickly learn to insert a space before the open paren to work around Emacs' font-lock deficiencies. The Climacs text editor is a combination of frameworks for buffer -representation and parsing parsing, loosely coupled with a CLIM-based -display engine. It includes the Flexichain library \cite{flexichain}, -which provides an editable sequence representation and mark (cursor) -management based on a linked lists of lines, some of which are represented as a circular gap buffer; and an implementation of a +representation and parsing, loosely coupled with a CLIM-based display +engine. It includes the Flexichain library \cite{flexichain}, which +provides an editable sequence representation and mark (cursor) +management using a simple linked lists used for implementing the +buffer protocol; and an implementation of a slight modification of the Earley parsing algorithm \cite{earley}, to -assist in the creation of syntax-aware editing modes. An application can combine a particular implementation of the buffer protocol, the syntax protocol, and its own display methods to produce a sophisticated editor for a particular language. +assist in the creation of syntax-aware editing modes. An application +can combine a particular implementation of the buffer protocol, the +syntax protocol, and its own display methods to produce a +sophisticated editor for a particular language. The Climacs buffer protocol, which provides a standard interface to common text editor buffer operations, uses the Flexichain library; we @@ -115,13 +119,17 @@ buffer protocol is independent of any implementation of the protocol, which allows flexible representations of buffers. -Climacs provides an implementation of buffers as a 2-3-tree of lines. -A line can be considered opened or closed. Editing operations are -performed on opened lines, which are represented as a cursorchain. A -fixed number of lines are kept opened according to a LRU scheme. When -a line is closed it is converted to a vector. If the line contains -only base-char objects this vector is a base-string; otherwise, it is -unspecialized. +The aim is for Climacs to provide several implementations of the +buffer protocol, one of which will use a sequence of lines organized +into a tree for quick access. In this implementation, a line can be +considered opened or closed. Editing operations are performed on +opened lines, which are represented as a cursorchain (a Flexichain +with an arbitrary number of cursors). A fixed number of lines are kept +opened according to a LRU scheme. When a line is closed it is +converted to a vector. If the line contains only base-char objects +this vector is a base-string; otherwise, it is unspecialized. +Currently, however, Climacs uses a single cursorchain for the entire +buffer, in effect making it a simple gap-buffer implementation. ``Protocol'' is not just an empty claim, as there are already multiple buffer implementations: Aleksandr Bakic's persistent buffer

1 0

[climacs-cvs] CVS update: papers/ilc2005/syntax/climacssyntax.tex
by bmastenbrook＠common-lisp.net 21 May '05

21 May '05

Update of /project/climacs/cvsroot/papers/ilc2005/syntax In directory common-lisp.net:/tmp/cvs-serv28137 Modified Files: climacssyntax.tex Log Message: MORE SYNTAX Date: Sat May 21 22:14:00 2005 Author: bmastenbrook Index: papers/ilc2005/syntax/climacssyntax.tex diff -u papers/ilc2005/syntax/climacssyntax.tex:1.10 papers/ilc2005/syntax/climacssyntax.tex:1.11 --- papers/ilc2005/syntax/climacssyntax.tex:1.10 Sat May 21 18:32:16 2005 +++ papers/ilc2005/syntax/climacssyntax.tex Sat May 21 22:14:00 2005 @@ -58,33 +58,38 @@ \section{Introduction} The field of advanced text editors is a crowded one, with a long -history and an apparent ability to cause passionate argument. Climacs is philosophically part of the Emacs editor tradition, which has spawned many variants with many different approaches to buffer management, incremental redisplay, and syntax analysis. +history and an apparent ability to cause passionate argument. Climacs is philosophically part of the Emacs editor tradition, which has spawned many variants with many different approaches to buffer management, incremental redisplay, and syntax analysis. Emacs itself traces its lineage to TECO, where Emacs was originally implemented as a set of TECO macros. Climacs is compared to several interesting variants of Emacs in Table \ref{table:editorcompare}. -\begin{itemize} -\item TECO -\item emacs (Zmacs) (emacs time line) \cite{greenberg} -\item some kind of interlispy/smalltalky structure editor? -\item Z -- the 95\% text editor \cite{woodZ}. Note that WiB didn't - win! -\item Plan9 / Acme (mouse-oriented) \cite{Pike94} -\end{itemize} +\begin{figure*} \begin{center} +\begin{tabular}{|c|c|c|c|c|} +\hline \textbf{Editor} & \textbf{Buffer Implementation} & \textbf{Syntax Analysis} & \textbf{Language} +\\ +\hline TECO & Gap Buffer & Unknown & Assembly + TECO Macros +\\ +\hline Zmacs & Probably doubly-linked list of lines & None & MacLisp +\\ +\hline GNU Emacs & Gap Buffer & Regular Expressions & C + Emacs Lisp +\\ +\hline Hemlock & Doubly-linked list of lines & None & Common Lisp +\\ +\hline FRED & Gap Buffer & None & PPC Assembly + Common Lisp +\\ +\hline Deuce & Doubly-linked lists of lines & Unknown & Dylan +\\ +\hline Climacs & Multiple & Multiple & Common Lisp +\\\hline +\end{tabular} +\caption{Implementation strategies of multiple Emacs variants} \end{center} \label{table:editorcompare} \end{figure*} -Discuss lameness of emacs-like regexoid analysis in e.g. CL mode; -maybe mention how it falls over dramatically in perl mode (where -context starts really mattering) -\begin{itemize} -\item non-locality leading to confusion in \verb+#| |#+ -\item paren-in-column-1 hack (and its workaround in docstrings: - \verb+\(+) -\end{itemize} +Climacs' syntax analysis is a flexible protocol which can be implemented with a full language lexer and parser. GNU Emacs, the most commonly used Emacs-like editor, uses regular expressions for its syntax analysis. Because these regular expressions are applied lazily and not on the whole buffer, constructs such as Common Lisp's nestable \verb+#| |#+ block comments will often confuse the regular expressions. If the parser starts after the opening \verb+#|+ then the closing \verb+|#+ will be treated as the start of an escaped symbol name. Even if the regular expression parses the whole block comment correctly, other expressions can still match on the contents of the comment, leading to issues when the first character in a column in the block comment is the start of a definition. Emacs users quickly learn to insert a space before the open paren to work around Emacs' font-lock deficiencies. The Climacs text editor is a combination of frameworks for buffer representation and parsing parsing, loosely coupled with a CLIM-based display engine. It includes the Flexichain library \cite{flexichain}, which provides an editable sequence representation and mark (cursor) -management based on a circular gap buffer; and an implementation of a +management based on a linked lists of lines, some of which are represented as a circular gap buffer; and an implementation of a slight modification of the Earley parsing algorithm \cite{earley}, to -assist in the creation of syntax-aware editing modes. +assist in the creation of syntax-aware editing modes. An application can combine a particular implementation of the buffer protocol, the syntax protocol, and its own display methods to produce a sophisticated editor for a particular language. The Climacs buffer protocol, which provides a standard interface to common text editor buffer operations, uses the Flexichain library; we

1 0

[climacs-cvs] CVS update: papers/ilc2005/syntax/climacssyntax.bib papers/ilc2005/syntax/climacssyntax.tex
by bmastenbrook＠common-lisp.net 21 May '05

21 May '05

Update of /project/climacs/cvsroot/papers/ilc2005/syntax In directory common-lisp.net:/tmp/cvs-serv15600 Modified Files: climacssyntax.bib climacssyntax.tex Log Message: Date: Sat May 21 18:32:16 2005 Author: bmastenbrook Index: papers/ilc2005/syntax/climacssyntax.bib diff -u papers/ilc2005/syntax/climacssyntax.bib:1.5 papers/ilc2005/syntax/climacssyntax.bib:1.6 --- papers/ilc2005/syntax/climacssyntax.bib:1.5 Fri May 20 16:44:55 2005 +++ papers/ilc2005/syntax/climacssyntax.bib Sat May 21 18:32:16 2005 @@ -145,4 +145,12 @@ year = {1994}, pages = {223-234}, bibsource = {DBLP, http://dblp.uni-trier.de} +} + +@book{FinsethCraft, + author = {Craig A. Finseth}, + title = {The Craft of Text Editing}, + publisher = {Springer-Verlag}, + year = {1991, 1999--}, + note = {http://www.finseth.com/craft} } Index: papers/ilc2005/syntax/climacssyntax.tex diff -u papers/ilc2005/syntax/climacssyntax.tex:1.9 papers/ilc2005/syntax/climacssyntax.tex:1.10 --- papers/ilc2005/syntax/climacssyntax.tex:1.9 Fri May 20 16:44:55 2005 +++ papers/ilc2005/syntax/climacssyntax.tex Sat May 21 18:32:16 2005 @@ -33,7 +33,7 @@ \affaddr{Motorola}\\ \affaddr{1303 E. Algonquin Road}\\ \affaddr{Schaumburg, IL, USA 60196}\\ - \email{Brian.Mastenbrook(a)motorola.com} + \email{brian(a)mastenbrook.net} } \maketitle @@ -58,13 +58,10 @@ \section{Introduction} The field of advanced text editors is a crowded one, with a long -history and an apparent ability to cause passionate argument. - -[ Does anyone know enough about the history of editors? ] +history and an apparent ability to cause passionate argument. Climacs is philosophically part of the Emacs editor tradition, which has spawned many variants with many different approaches to buffer management, incremental redisplay, and syntax analysis. \begin{itemize} -\item ed -\item vi (vim) +\item TECO \item emacs (Zmacs) (emacs time line) \cite{greenberg} \item some kind of interlispy/smalltalky structure editor? \item Z -- the 95\% text editor \cite{woodZ}. Note that WiB didn't

1 0

[climacs-cvs] CVS update: papers/ilc2005/syntax/climacssyntax.bib papers/ilc2005/syntax/climacssyntax.tex
by crhodes＠common-lisp.net 20 May '05

20 May '05

Update of /project/climacs/cvsroot/papers/ilc2005/syntax In directory common-lisp.net:/tmp/cvs-serv17307 Modified Files: climacssyntax.bib climacssyntax.tex Log Message: One more prehistoric editor reference Date: Fri May 20 16:44:55 2005 Author: crhodes Index: papers/ilc2005/syntax/climacssyntax.bib diff -u papers/ilc2005/syntax/climacssyntax.bib:1.4 papers/ilc2005/syntax/climacssyntax.bib:1.5 --- papers/ilc2005/syntax/climacssyntax.bib:1.4 Fri May 20 15:35:22 2005 +++ papers/ilc2005/syntax/climacssyntax.bib Fri May 20 16:44:55 2005 @@ -136,4 +136,13 @@ isbn = {0-89791-050-8}, pages = {1--7}, location = {Portland, Oregon, United States}}, - } \ No newline at end of file + } + +@inproceedings{Pike94, + author = {Rob Pike}, + title = "{Acme: A User Interface for Programmers}", + booktitle = {USENIX Winter}, + year = {1994}, + pages = {223-234}, + bibsource = {DBLP, http://dblp.uni-trier.de} +} \ No newline at end of file Index: papers/ilc2005/syntax/climacssyntax.tex diff -u papers/ilc2005/syntax/climacssyntax.tex:1.8 papers/ilc2005/syntax/climacssyntax.tex:1.9 --- papers/ilc2005/syntax/climacssyntax.tex:1.8 Fri May 20 15:35:22 2005 +++ papers/ilc2005/syntax/climacssyntax.tex Fri May 20 16:44:55 2005 @@ -69,6 +69,7 @@ \item some kind of interlispy/smalltalky structure editor? \item Z -- the 95\% text editor \cite{woodZ}. Note that WiB didn't win! +\item Plan9 / Acme (mouse-oriented) \cite{Pike94} \end{itemize} Discuss lameness of emacs-like regexoid analysis in e.g. CL mode; @@ -81,9 +82,9 @@ \end{itemize} The Climacs text editor is a combination of frameworks for buffer -representation and buffer contents parsing with a CLIM-based display -engine. It includes the Flexichain library \cite{flexichain}, which -provides an editable sequence representation and mark (cursor) +representation and parsing parsing, loosely coupled with a CLIM-based +display engine. It includes the Flexichain library \cite{flexichain}, +which provides an editable sequence representation and mark (cursor) management based on a circular gap buffer; and an implementation of a slight modification of the Earley parsing algorithm \cite{earley}, to assist in the creation of syntax-aware editing modes. @@ -120,6 +121,12 @@ only base-char objects this vector is a base-string; otherwise, it is unspecialized. +``Protocol'' is not just an empty claim, as there are already multiple +buffer implementations: Aleksandr Bakic's persistent buffer +implementation, providing a cheap implementation of the undo protocol. +(FIXME: a citation, either to something ``in preparation'' or to some +previous description of the ideas?) + \section{Syntax Protocol} \label{sec:syntax} @@ -268,7 +275,14 @@ Ornaments are simple to model, as they are merely modifiers to note objects; higher-level grouping things (beams, connecting lines) have their own semi-independent identity, despite not being notated as such -in the textual \TabCode. +in the textual \TabCode. Beams and connecting lines can overlap +(thinking linearly, not on the manuscript!) in non-trivial ways: + +\begin{verbatim} + [ beamed section ] + word word word word word + ^____ line ____^ +\end{verbatim} Need whole-buffer function to present an alternative whole-system view on the data.

1 0

[climacs-cvs] CVS update: papers/ilc2005/syntax/climacssyntax.bib papers/ilc2005/syntax/climacssyntax.tex
by crhodes＠common-lisp.net 20 May '05

20 May '05

Update of /project/climacs/cvsroot/papers/ilc2005/syntax In directory common-lisp.net:/tmp/cvs-serv13676 Modified Files: climacssyntax.bib climacssyntax.tex Log Message: One or two more things that we might want to discuss Date: Fri May 20 15:35:22 2005 Author: crhodes Index: papers/ilc2005/syntax/climacssyntax.bib diff -u papers/ilc2005/syntax/climacssyntax.bib:1.3 papers/ilc2005/syntax/climacssyntax.bib:1.4 --- papers/ilc2005/syntax/climacssyntax.bib:1.3 Fri May 20 13:48:40 2005 +++ papers/ilc2005/syntax/climacssyntax.bib Fri May 20 15:35:22 2005 @@ -130,7 +130,7 @@ @inproceedings{woodZ, author = {Steven R. Wood}, - title = "{Z -- the 95\% program editor}", + title = "{Z -- The 95\% Program Editor}", booktitle = {Proceedings of the ACM SIGPLAN SIGOA symposium on Text manipulation}, year = {1981}, isbn = {0-89791-050-8}, Index: papers/ilc2005/syntax/climacssyntax.tex diff -u papers/ilc2005/syntax/climacssyntax.tex:1.7 papers/ilc2005/syntax/climacssyntax.tex:1.8 --- papers/ilc2005/syntax/climacssyntax.tex:1.7 Fri May 20 13:48:41 2005 +++ papers/ilc2005/syntax/climacssyntax.tex Fri May 20 15:35:22 2005 @@ -186,6 +186,12 @@ Possibility (probably ``Future Work'') to make nice integrated Prolog environment. +At present, one parse error implies the invalidation of the rest of +the file. This adds a burden on the mode implementor that the syntax +analyser be both bug-free and correspond with reality; a +slightly-buggy or incomplete syntax mode will render the whole thing +useless. Violation of WiB? + The TTCN3 syntax is implemented with a high-level macro which defines classes and adds syntax rules using the syntax protocol for each terminal and non-terminal in the grammar. The syntax of this macro @@ -243,11 +249,11 @@ 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 +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, beaming, connecting lines and other -complex elements can all be accommodated (see figure \ref{fig:barley} -for examples of more these more complex elements). +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 more these more complex elements). \TabCode\ has been used to produce scholarly editions of lute works \cite{Weiss} and to computer-based musicological studies (as in

1 0

[climacs-cvs] CVS update: papers/ilc2005/syntax/barley.eps papers/ilc2005/syntax/barley.pdf papers/ilc2005/syntax/climacssyntax.bib papers/ilc2005/syntax/climacssyntax.tex
by crhodes＠common-lisp.net 20 May '05

20 May '05

Update of /project/climacs/cvsroot/papers/ilc2005/syntax In directory common-lisp.net:/tmp/cvs-serv7313 Modified Files: climacssyntax.bib climacssyntax.tex Added Files: barley.eps barley.pdf Log Message: Add a couple of editor references Rearrange the introduction a little bit add another figure of more complex tablature Date: Fri May 20 13:48:41 2005 Author: crhodes Index: papers/ilc2005/syntax/climacssyntax.bib diff -u papers/ilc2005/syntax/climacssyntax.bib:1.2 papers/ilc2005/syntax/climacssyntax.bib:1.3 --- papers/ilc2005/syntax/climacssyntax.bib:1.2 Tue May 17 14:56:23 2005 +++ papers/ilc2005/syntax/climacssyntax.bib Fri May 20 13:48:40 2005 @@ -117,3 +117,23 @@ OPTannote = {} } +@inproceedings{greenberg, + author = {Bernard S. Greenberg}, + title = "{Multics Emacs (Prose and Cons): A commercial text-processing system in Lisp}", + booktitle = {LFP '80: Proceedings of the 1980 ACM conference on LISP and functional programming}, + year = {1980}, + pages = {6--12}, + location = {Stanford University, California, United States}, + publisher = {ACM Press}, + address = {New York, NY, USA}, +} + +@inproceedings{woodZ, + author = {Steven R. Wood}, + title = "{Z -- the 95\% program editor}", + booktitle = {Proceedings of the ACM SIGPLAN SIGOA symposium on Text manipulation}, + year = {1981}, + isbn = {0-89791-050-8}, + pages = {1--7}, + location = {Portland, Oregon, United States}}, + } \ No newline at end of file Index: papers/ilc2005/syntax/climacssyntax.tex diff -u papers/ilc2005/syntax/climacssyntax.tex:1.6 papers/ilc2005/syntax/climacssyntax.tex:1.7 --- papers/ilc2005/syntax/climacssyntax.tex:1.6 Fri May 20 10:18:33 2005 +++ papers/ilc2005/syntax/climacssyntax.tex Fri May 20 13:48:41 2005 @@ -55,21 +55,55 @@ \keywords{Editors, Parsing, Tablature} -\section{Overview} +\section{Introduction} + +The field of advanced text editors is a crowded one, with a long +history and an apparent ability to cause passionate argument. + +[ Does anyone know enough about the history of editors? ] + +\begin{itemize} +\item ed +\item vi (vim) +\item emacs (Zmacs) (emacs time line) \cite{greenberg} +\item some kind of interlispy/smalltalky structure editor? +\item Z -- the 95\% text editor \cite{woodZ}. Note that WiB didn't + win! +\end{itemize} + +Discuss lameness of emacs-like regexoid analysis in e.g. CL mode; +maybe mention how it falls over dramatically in perl mode (where +context starts really mattering) +\begin{itemize} +\item non-locality leading to confusion in \verb+#| |#+ +\item paren-in-column-1 hack (and its workaround in docstrings: + \verb+\(+) +\end{itemize} The Climacs text editor is a combination of frameworks for buffer representation and buffer contents parsing with a CLIM-based display -engine. The Flexichain library \cite{flexichain} provides an editable -sequence representation and mark (cursor) management based on a -circular gap buffer. This library is used by the buffer protocol, -which provides a standard interface to common text editor buffer -operations. The syntax protocol provides a method for interfacing a -lexical analyzer and parser with the text editor. An implementation of -the Earley parsing algorithm is provided to simplify the creation of -syntaxes for common context-free grammars. Syntax modules also define -methods to draw syntax objects in the Climacs window. +engine. It includes the Flexichain library \cite{flexichain}, which +provides an editable sequence representation and mark (cursor) +management based on a circular gap buffer; and an implementation of a +slight modification of the Earley parsing algorithm \cite{earley}, to +assist in the creation of syntax-aware editing modes. + +The Climacs buffer protocol, which provides a standard interface to +common text editor buffer operations, uses the Flexichain library; we +discuss this protocol in more detail in section \ref{sec:buffer}. The +syntax protocol, which we discuss in section \ref{sec:syntax}, +provides a method for interfacing a lexical analyzer and parser with +the text editor, and provides for defining methods to draw syntax +objects in the Climacs window. In section \ref{sec:syntaxes} we +discuss the implementation of syntactic analysis for various +programming languages, including Common Lisp; in section +\ref{sec:tabeditor}, we discuss an application with Climacs at its +core to support editing a textual representation of lute tablature. +We discuss avenues for further development in section +\ref{sec:conclusions}. \section{Buffer Protocol} +\label{sec:buffer} The buffer protocol provides a set of methods for modifying and reading the contents of a buffer which can contain arbitrary objects. @@ -87,6 +121,7 @@ unspecialized. \section{Syntax Protocol} +\label{sec:syntax} A syntax in Climacs is an incremental parser which creates and updates a parse tree of a buffer's contents, and provides a mechanism for @@ -103,16 +138,20 @@ other display or analysis of the text in the buffer. Earley parser: discussion of generality and asymptotic efficiency (in -general and for usual cases). +general and for usual cases). Possibility of replacement in case of +complicated grammars? (What was that parsing algorithm that someone +mentioned on \verb+#lisp+?) \section{Syntaxes} +\label{sec:syntaxes} We describe two different approaches to syntax analysis in the Climacs editor. Per-window parsing is used by the provided modes for HTML, Common Lisp, Prolog, and TTCN3. Each of these syntaxes is implemented with the provided Earley parser \cite{earley}. The lute tablature editor uses a per-buffer function for its syntax analysis and -implements a simple recursive-descent parsing algorithm. +implements a simple recursive-descent parsing algorithm. (FIXME: is +this true? I don't know enough about parsing) \subsection{Per-Window Syntaxes} @@ -157,7 +196,8 @@ macro defines basic display functions for the syntax objects produced by the parser, with language keywords appearing in a separate color. -\subsection{Per-Buffer Syntax} +\subsection{Per-Buffer Syntax: a tablature editor} +\label{sec:tabeditor} \begin{figure*} \begin{center} @@ -178,6 +218,26 @@ \end{center} \end{figure*} +\begin{figure*} + \begin{center} + \parbox{0.45\linewidth}{\includegraphics{barley}} + \parbox{0.25\linewidth}{\texttt{\\ [1cm]\noindent + Sa1(E)d5(C5:8)\\ + a2.\\ + d3\\ + b3.\\ + d3\\ + a2.\\ + a1:\\ + d3.(C-5:4)\\ + |}} + \caption{An extract from `Lachrime by I. D.' from \textit{A New + Booke of Tabliture}, published by William Barley (London, + 1596), E1r, and its \TabCode\ encoding.} + \label{fig:barley} + \end{center} +\end{figure*} + \TabCode\ is a textual format for description of lute tablature. In its simplest form, it is a sequence of whitespace-delimited independent words, where each word represents either a set of frets to @@ -186,7 +246,8 @@ 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, beaming, connecting lines and other -complex elements can all be accommodated. +complex elements can all be accommodated (see figure \ref{fig:barley} +for examples of more these more complex elements). \TabCode\ has been used to produce scholarly editions of lute works \cite{Weiss} and to computer-based musicological studies (as in @@ -216,9 +277,11 @@ MIDI feedback. At present, based on Apple's extremely badly documented CoreMIDI framework; a port to alsalib is on the cards. -\section{Conclusion} +\section{Future Work and Conclusions} +\label{sec:conclusions} -I like Jello. Jello is good. +I like Jello. Jello is good. We should enable people to make better +Jello. \nocite{*}

1 0

← Newer
1
...
51
52
53
54
55
56
57
...
85
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

climacs-cvs