Proxima Home
Gallery
Download
Documentation
   Proxima Client
   Proxima Server
   Proxima Engine
   Building an editor
   User manual
Publications
Contribute
Bug reporting
Oblomov Systems

Work Plan Completed

Proxima

Dazzle documentation editor

The Dazzle documentation editor is an instantiation of Proxima used in the Dazzle project. Currently there is a working prototype, not yet ready for release. This section concerns issues that need to be addressed in order to make the Dazzle editor practically usable.

Layout navigation

At the moment, any scrolling action is performed with the mouse. To provide more pleasant editing, moving the cursor when it is at the edge of the screen should scroll the rendering and show the new position of the cursor. Pressing page up or page down should scroll the rendering by approximately the screen height.

The situation is slightly complicated by the fact that the arrangement is computed only for the part of the presentation that is visible on the screen. Navigation operations to unarranged subtrees, require the higher layers to re-present the appropriate parts of the document. This may involve a slight change to the architecture that will allow a single edit event to cause more than one parse/present cycle.

Scanner

The scanner takes a Layout tree (containing rows, columns, and strings) and tokenizes the subtrees that are going to be parsed. It is implemented as a recursive function that inspects all strings in the presentation and creates a list of tokens. For each token the preceding whitespace is recorded in a list, and its presentation identity is recovered as much as possible. The current version of the scanner works, but supports a limited number of tokens and is hard to extend.

A new scanner is needed, which uses an attribute grammar to traverse the tree. This makes it easier to keep track of identities and whitespace (which are now threaded through the computation by hand). Furthermore, rather than hard code the different kinds of tokens, a specification in the form of regular expressions should be used. This will allow the complete separation between the generic scanner and the scanner sheet that is provided by the editor designer.

To handle several languages in one editor instance, it must be possible to specify several sets of tokens, and put annotations in the presentation regarding which set to use.

Undo (partially done)

Proxima's layered architecture restricts edit operations its data structures to a small number of places. Therefore, the implementation of undo will be largely orthogonal to the rest of the systems. A few aspects complicate the matter though. Firstly, data exists at several levels in Proxima and because of extra state, no single level contains all the information required for complete undo. Secondly, not every edit event leads to a complete parse/present cycle from the rendering to the document and back. For instance, during presentation editing, only the lower layers are active, until the presentation is parsed. As a consequence, the levels may not always be consistent with each other, which must be taken into account when implementing undo.

Recover presentation focus

When a presentation is parsed, and re-presented, the presentation structure may change (e.g. when "1 / 2" is presented as a fraction with a horizontal bar). This causes the presentation focus to be lost. This happens even when simply editing a paragraph. Because entering a character uses generic algorithms, inserting an 'a' in the middle of String "Bla" yields Row [String "B", String "l", String "a"]. Now the focus is lost on parsing an re-presenting, since the focus immediately after the edit operation is represented (not re-presented) by the path [2,1] whereas in the result of the presentation (String "Bla") this focus should be [2]. In this case the focus is a prefix of the old focus, but this is not the case in general.

A simple solution is to add special cases for inserting and deleting in strings, which do not add the extra row. However, to recover the focus after changes to the presentation structure, we need a more advanced solution. We could store focus information in tokens and have the parser store this information in the document. But it is also possible to keep the focus at the presentation layer and have the document reuse its old tokens, thus restoring the focus. (This is similar to the whitespace reuse in the Helium editor.)

Edit model and Edit operations

Find/replace

Find and find next occurrence have been implemented.

Longer term

The following issues are not strictly necessary for the Dazzle documentation editor, although several may increase its useability and maintainability.

Default support for handling parse errors

Currently, parse errors are sent to the command line. It will be relatively easy to provide default attribution for parse-error nodes in the document that allows a textual representation of a parse error to be included in the presentation. For the presentation of the parse error node, the presentation that failed to parse is used. The location of the parse error can be used to show the location of the error in the presentation. If the parse error is marked in the presentation with a squiggly line or something similar, the marking needs to have some kind of annotation in order to be able to remove it during editing, and prevent markings from building up during editing in the unparseable presentation.

Rewrite of the generator

The generator is a separate Haskell program that takes a document type definition (DocumentTypeDefinition.hs) and generates the Proxima modules with names ending in "_Generated". This includes the Haskell document type with utility functions and instances of the Editable class, as well as default attribution rules in PresentationAG_Generated.ag

The current implementation of the generator is messy and has a very low abstraction level. This may cause problems in code generation for certain identifier names. Moreover, it is hard to extend the generator. The generator therefore needs to be rewritten from scratch.