> Manipulating graphs, er, graphically, will not give you some sort of magical get-out-of-jail-free card against syntax errors or undefinable behaviour etc. It

> Manipulating graphs, er, graphically, will not give you some sort of magical get-out-of-jail-free card against syntax errors or undefinable behaviour etc. It does prevent some errors, like malformed structures. For example, the following Lisp: (defun (square x (* x x)) Or the following C: void square(int x { return x * x; Or the following Ruby: while $i < $num do puts "Inside the loop i = #$i) $i +=1 These sorts of things can occur when manipulating programs at the character level, but they're inexpressible at the level of parse trees/graphs. Balancing parentheses, braces, quotation marks, begin/end, etc. is exactly the sort of task that machines can automate away. The idea of a general tree editor is not to prevent syntax errors, undefined behaviour, etc. because those are properties of specific trees, e.g. the parse trees of C programs. A tree editor just edits trees; it doesn't care what those trees represent (that's why the author mentions a plugin mechanism, like Emacs has different modes for editing files written in different languages). Manipulating programs at the level of parse trees can also be more efficient, less tedious and prevent errors, e.g. see the paredit videos linked in other comments. By analogy, what's the point of a general text editor, when our CPU can already perform arithmetic on bytes? A general text editor doesn't prevent syntax errors, undefined behaviour, etc. Does editing strings of text, rather than numerical bytes, provide expressive power or syntactic clarity that we don't have with high-level languages already? I also don't think the author was asking for something "graphical" or "GUI" per se; their analogy is with text editors (e.g. Emacs and Vi), which are efficient both in their display and their interaction. A general tree editor wouldn't be based around e.g. drag'n'drop of nodes/edges, in the same way that general text editors aren't based around drag'n'drop of glyphs in a grid. General text editors have features for moving to the start/end of a line, for cut/paste up to the next space or linefeed, for highlighting parentheses, for folding/unfolding between sentinel characters, etc. General tree editors would instead have features to move to the root/leaf of a tree, cut/paste sub-terms, fold/unfold expressions, etc. No need to care about the existence of whitespace, linefeeds, indentation, parentheses/delimiters, etc. they can all be handled mechanically.