The point of this article is to try to describe the approach to developing an application within this editor.
A substantial motivation for this editor was the (apparent) difficulty in writing applications for EMACS. The difficulty lies in the need to worry about the wrong sort of detail. In EMACS that display is very tightly tied to the buffer contents. It is possible to hide parts of the buffer, and to display parts of the buffer differently, but the level of abstraction seems all wrong. There needs to be a clearer separation between the buffer and the display, with the option of arbitrary programatic conversion from buffer to display.
For this to be achievable without simply introducing a different sort of complexity there needs to be a clear model explaining how things should work.
The first observation is that all lasting data associated with a document should be stored in the documents buffer as text.
While the structure of this data can be stored in attributes, and these attributes can store summary information, the attributes should always be treated as expendable. If there is any change in the document buffer, the attributes may well be discarded and need to be reparsed. Thus the attributes are for efficient access to the data but shouldn't be used for primary storage.
The Python document object has room for storing arbitrary information about a document. This should be used for high level status information. It might include metadata about the whole document but should not store anything about components of the document. They must be stored in the document buffer itself.
As information may need to be parsed out of the document at any time (though normally not very often) the information stored in the buffer should be stored in a way that makes it easy to parse. This does not need to reflect how the information will be displayed, as the displayed images may well be generated from attribute metadata rather than literal content.
If the display might want to re-order the contents of the buffer, the elements that need to be reordered should contain appropriate linkage information. This would require each element to have an identity (e.g. a sequential number) and to have forward and backward links for each possible sequence that the element is in.
When part of a document is to be displayed, (how does this look, what is next, what is before)
