3 ms·

I'm pretty sure "a text editor that bitches at you and won't let you type incorrect stuff" isn't the answer and I'm pretty sure "a text editor in which clippy p

by frig 18y ago

I'm pretty sure "a text editor that bitches at you and won't let you type incorrect stuff" isn't the answer and I'm pretty sure "a text editor in which clippy pops up and is like "you seem to have forgotten a parentheses. Can I help you figure out where to put it" isn't the answer, either; if I had an inkling about what a good ui would be I'd tell you or be working on this myself, but I don't have any real insight beyond what I've shared. You might want to start by getting a list together of the various refactorings / simple structure transforms you encounter a lot in eg the lisp you write, and then figuring out what the best keyboard interface would be just for manually inputting a sequence of those transformations.

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

by frig 18y ago

Hexstream 18y ago

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.