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.
Structure editing has often been employed in source code editors. 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).
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 PAG ) or a logic program (e.g., as in Centaur and Pan), with compliance checked by the underlying editing machinery.
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).