A structure editor, also structured editor or projectional editor, is any document editor that is cognizant of the document’s underlying structure. Structure editors can be used to edit hierarchical or marked up text, computer programs, diagrams, chemical formulas, and any other type of content with clear and well-defined structure. In contrast, a text editor is any document editor used for editing plain text files.
Typically, the benefits of text and structure editing are combined in the user interface of a single hybrid tool. For example, Emacs is fundamentally a text editor, but supports the manipulation of words, sentences, and paragraphs as structures that are inferred from the text. Conversely, Dreamweaver is fundamentally a structure editor for marked up web documents, but supports the display and manipulation of raw HTML text as well. Similarly, molecule editors typically support both graphical and textual input. Structure editing predominates when content is graphical and textual representations are awkward, e.g., CAD systems and PowerPoint. Text editing predominates when content is largely devoid of structure, e.g., text fields in web forms. WYSIWYG word processing systems such as Word, which appear to edit formatted text directly, are essentially structure editors for the underlying marked-up text.
In linguistics, syntax is the study of the structure of grammatical utterances, and accordingly syntax-directed editor is a synonym for structure editor. Language-based editor and language-sensitive editor are also synonyms. A language-based editor’s features may be implemented by ad hoc code or by a formal grammar. For example, language sensitivity in Emacs is implemented in the Lisp definition of the edit mode for the given language. In contrast, language sensitivity in an XML editor is driven by a formal DTD schema for the given language.
Although structured editors allow the viewing and manipulation of the underlying document in a structured manner, the file format in which the document is stored on disk may or may not be heavily structured and may or may not be open or standardized (e.g., plain text versus Microsoft Word documents).
Source code editors
Structure editing has often been employed in source code editors, as source code is naturally structured by the syntax of the computer language. However, most source code editors are instead text editors with additional features such as syntax highlighting and code folding, rather than structure editors. The editors in some integrated development environments parse the source code and generate a parse tree, allowing the same analysis as by a structure editor, but the actual editing of the source code is generally done as raw text.
Each programming language typically has a well-defined syntax given by a context-free grammar, and accordingly the meaningful structural elements in source code written in the language correspond to the grammatical phrases in the text. Early syntax-directed source code editors included Interlisp-D (for Lisp’s limited syntax) and Emily (for PL/I’s rich syntax).
A syntax-directed editor may treat grammar rules as generative (e.g., offering the user templates that correspond to one or more steps in a formal derivation of program text) or proscriptive (e.g., preventing a phrase of a given part of speech from being moved to a context where another part of speech is required) or analytic (e.g., parsing textual edits to create a structured representation). Structure editing features in source code editors make it harder to write programs with invalid syntax. Language-sensitive editors may impose syntactic correctness as an absolute requirement (e.g., as did Mentor), or may tolerate syntax errors after issuing a warning (e.g., as did the Cornell Program Synthesizer). Strict structured editors often make it difficult to perform edits that are easy to perform with plain text editors, which is one of the factors contributing to the lack of adoption of structured editing in some domains, such as source code editing.
Some syntax-directed editors monitor compliance with the context-sensitive constraints of a language such as type correctness. Such static-semantic constraints may be specified imperatively by actions (e.g., as in Gandalf), or declaratively by an attribute grammar (e.g., as in the Synthesizer Generator) or by unification in a many-sorted algebra (e.g., as in PSG ) or a logic program (e.g., as in Centaur and Pan), with compliance checked by the underlying editing machinery. Structured editors vary in the degree to which they allow their users to perform edits that cause the document to become syntactically or semantically incorrect.
It is common for a language sensitive editor to represent a document as a parse tree with respect to language’s grammar, or as an abstract syntax tree (AST). For example, a DOM tree is essentially an AST with respect to a given DTD. Frequently, the textual view of that underlying tree is generated by prettyprinting the underlying tree. Editors associated with intentional programming and language-oriented programming for general-purpose languages and domain-specific languages share many of the features of language-sensitive editors, but aim for greater separation between the underlying representation (the intention) and the surface representation (text in a programming language).