3 ms·

I acknowledge the validity of the concerns you're bringing up here. I've just started thinking about this a few months ago and I haven't spent any time trying

I acknowledge the validity of the concerns you're bringing up here. I've just started thinking about this a few months ago and I haven't spent any time trying to actually implement my ideas yet, so there are indeed quite a few issues I haven't explored very deep or indeed not at all. I had thought a bit about the potential rigidity tradeoffs of correctness VS usability. I hadn't really thought about going so far as enforcing function signatures, though it's the logical next step after enforcing s-expression validity. There are lots of different types of "structure errors" and I think some should be strictly enforced while others shouldn't. In the s-expression case, one example of something that should be enforced strictly is the nesting of parentheses that delimit s-expressions. Fortunately that one is pretty easy. Wereas in a traditional editor you'd do: (| ()| (|) as 3 different steps, in a structure editor you'll simply have one operation that will do all this atomically so you go from one correct state to the next. In the function arity case, I think a much more lax enforcement is de rigueur. There will always be some editing tasks that will require less rigid rules but I think we should value correctness by default and then introduce laxity in controlled ways where it makes sense. It's a tradeoff similar to how limiting side-effects by default is a restriction that can make a program more powerful, yet sometimes you really want to have some mutable state. edit: I'd add that my end goal for a structure editor is that it may better assist the user in his editing tasks by having a better understanding of the context. The validity enforcement is only a means to facilitate this and should be relaxed wherever it impedes the user rather than helping.

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.

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.