D23 TEXT

Overview

This part of the deliverable describes the Camille text editor plug-in.

Motivations

A number of frameworks for text editors are available, but EMF (Eclipse Modeling Framework Project) was quickly identified as the target candidate, in combination with TEF (Textual Editing Framework), which is based on EMF. The framework seamlessly integrates into Eclipse. It is already proven within Rodin, as it is the foundation of UML-B. It is extensible - contributors of other plug-ins will be able to extend the text editor as well. And last, a proof-of-concept prototype had been put together very quickly.

Rodin has done away with a textual representation of the formal models. Indeed, events, theorems, axioms, etc. are stored in the Rodin database, and there is no classical text file to edit the models. The models are directly manipulated by a structural form-based editor. During the lifetime of the Rodin and DEPLOY projects it became increasingly apparent that the current structural editor was not able to cope with some industrial needs. Functions that are taken for granted in an editor - unstructured copy & paste or printing, just to name a few - were missing or only partially functional.

As an Event-B model consists of text, users were requesting a text editor, which would allow them to apply their already present text editing skills. As text editing is a well-understood problem, a variety of frameworks were available to implement one. These frameworks typically provide a wide range of standard features "for free", and typically provide extension points for extendability with additional features. The development team selected the Eclipse Modeling Framework (EMF), for the reasons outlined below.

The wide adoption of the text editor confirms that good decisions have been made. Besides standard text editing features as cut & paste, unlimited undo and redo, line numbering and many more, many Rodin-specific features had been implemented. The text editor supports syntax and semantic highlighting, code completion, templates, an outline view, quick navigation and many more.

Choices / Decisions

One important design consideration was to be able to re-use the Rodin formula syntax and parser. This was deemed vital for keeping up with future evolutions of the platform, e.g. the mathematical extensions will introduce new operators. As such, the grammar had to be carefully designed to be able to parse the structure of an Event-B model independently of the content of the predicates, expressions and actions. In other words, the structural parser detects the structure of the model and sends the formula content to the Rodin parser.

There is a very important limitation of the editor; while it can cope with changes of the mathematical language, it is not able to automatically deal with changes to the model’s structure. If we need to add information to the structure of a model itself, such as information on decomposition or flows it is necessary to modify the parser’s grammar and recompile it. There is to our best knowledge only one tool for the Eclipse framework that allows modification of the grammar during runtime. In theory, the features of TEF perfectly fit our needs and indeed Alexei Iliasov developed in 2008 a prototype based on TEF. However there were a number of things that convinced us to not use it. First of all, the framework is released under the GNU Public License which is legally not compatible with the Eclipse Public License used in Rodin. Second, the parser RunCC used in TEF has some issues related to handling parse errors. Because the project did not make progress for three years it is very unlikely that these problems will be fixed by the creators of the parser. Extending RunCC could solve this problem but it does not seem to be feasible without major effort and resources. The grammar used to generate Camille’s parser is close to EBNF, so we think that it is not too difficult for plug-in developers to contribute to the grammar but one has to be careful to not restrict the current language, i.e. we can only add optional syntax elements to the grammar, otherwise we break older models. However, this does not mean that we cannot have new mandatory elements, it only means that it has to be checked by the underlying model instead of the parser.

We also considered the BE4 Framework as well as Eclipse XText; an early version of Camille was indeed based on BE4 and it still contains some of its basic concepts. The main reason to not use BE4 was that editors for EMF models are less strongly based on files than editors for other languages. The EMF framework has its own notification system for changes in models. These change notifications may be caused by file changes. In addition, changes to the model coming from other plug-ins may trigger notifications too. This means that a text editor needs to react, i.e. to run its compiling respectively updating processes according to these changes. Therefore a build process which is based on files as BE4 offers is rather unsuitable. XText was also considered and is a reasonable alternative to our approach. At the time we started developing Camille, the XText framework was not released and it was not clear if and when certain features are included. Also the API was not stable at that time. In contrast to our solution, XText has the advantage that it creates the parser from the EMF model.

The most challenging technical part was the synchronisation with the Rodin database, particularly in the presence of other tools concurrently manipulating the same model. To achieve this, we created a new abstraction of the Rodin database as an EMF (Eclipse Modelling Framework Project) data model. It allows us to work with Event-B models independently of the persistence strategy. In addition we can use EMF standard technologies for manipulating, comparing and merging of Event-B models.

The fit between the database model and the text representation posed a number of challenges. Users must be able to edit both in the text editor and the structural editor. However, the text editor provides much more freedom in formatting than the structural editor. The current implementation keeps the formatting of the user intact, unless changes through the structural editor are made. Also, comments cannot be placed anywhere, which is unintuitive in a text environment. This is due to the fact that the database allows comments only in certain places. Some constraints on permitted characters in labels and identifiers had to be made. In all these instances, meaningful error messages guide the user, and the editor attempts to be as unobtrusive as possible.

Available Documentation

Online Documentation

• Text Editor Wiki Page

• EBNF Syntax for the Textual Representation

Papers

• A Semantics-Aware Text Editor for Event-B. Fabian Fritz. Master's Thesis. 2009
• Developing Camille, a Text Editor for Rodin. Jens Bendisposto, Fabian Fritz and Michael Leuschel. 2009. (to appear in WS-TBFM 2010)

Planning

The Text Editor needs to be extended to support new attributes (e.g. stemming from the upcoming decomposition plug-in) and the upcoming mathematical extensions.

Users have expressed the desire to be able to insert comments everywhere. It is unclear whether this can be achieved without a major refactoring of the Rodin Database.