4 ms·

I didn't say the editor would bitch at you for entering incorrect stuff, it's that for a lot of things it would be impossible to enter incorrect stuff by design

I didn't say the editor would bitch at you for entering incorrect stuff, it's that for a lot of things it would be impossible to enter incorrect stuff by design and it would make editing easier and faster, not harder. If the only way to enter parentheses into your s-expressions is to invoke the open-sexp command by pressing the appropriate key, it's impossible that you'll forget a parenthesis or have them nested improperly (unless the nesting is syntactically correct). Correspondingly, to delete an element such as an s-expression you'll invoke the "delete-element" command so it's impossible that you'll just delete the last parenthesis of an s-expression without deleting the rest of it.

frig 18y ago
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.

frig 18y ago

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.