Sure, I was just enumerating obviously-wrong implementation ideas, not suggesting that's what I thought you were doing. What I was getting at is thinking of a

Sure, I was just enumerating obviously-wrong implementation ideas, not suggesting that's what I thought you were doing. What I was getting at is thinking of a structure editor as a text editor + extras might be a dead end, but I don't have any bright ideas for you as to what user-interface approach wouldn't be a dead end. Actually hold up, I have a possibility for you before I get back to the game. I could see maybe a case for a split-screen (split vertically into 1+N panes), where your currently-under-edit block is always in the (user-set fixed-size) pane, and the remaining options are like this (quasi-lisp): +----active pane----+ (define (exponentiate x y) |) +----first suggestion pane----+ [open-sexp] (define (exponentiate x y) (|)) +----second suggestion pane----+ [delete-sexp] (define |) +----third suggestion pane----+ [swap-args] (define (exponentiate y x) |) etc., with the basic metaphor being: The top pane has the current version of what you're working on. Each pane underneath it shows the result of applying one of the higher-level operations (like open-sexp or delete-sexp). For small syntax edits (like adding a matched pair) this mode is overkill; for fancier operations (invert nesting over some complicated structure) this makes it easy to visualize what you're going to get from each command. That's it, got to get back to the game. Good luck with your endeavors on this project; a better editor is a worthy cause.