> We can have editing methods that are character-based, yet which make those kinds of syntax errors impossible. Your example doesn't work very well, since it's

> We can have editing methods that are character-based, yet which make those kinds of syntax errors impossible. Your example doesn't work very well, since it's very specific (the author wants "general-purpose"), and I would say it's not actually a "character-based editing method": it has a keyboard-driven UI and a character-based display, but so does NetHack. Instead I'd say your example is a float editor, rather than a 'text editor with syntax rules'. In any case, there is an example which is close to a general-purpose tree editor that's is keyboard-driven with a character-based display: paredit mode in Emacs, as mentioned by other comments. It's implemented exactly like you describe: many keypresses correspond to the insertion of their respective characters, but when that would invalidate the tree structure (e.g. '(' and ')' keys), different actions are taken instead. For example, '(' inserts '()', whilst ')' "steps over" existing ')' characters rather than inserting extra ones. My issues with paredit, as I've written in other comments, are that it's stuck with a single representation of trees as parenthesised s-expressions: there's no way to alter the "view" of a tree, e.g. to a boxes-on-sticks view or a nested-boxes view (whether they're displayed using ASCII art or GUI widgets). It also leaks implementation details, e.g. altering the alignment or indentation of expressions will cause the file contents to change, despite having nothing to do with a tree.