4 ms·

Structural editing is something that seems like a great idea to me but that I feel wouldn’t work for me in practice. The context sensitivity of actions would dr

Structural editing is something that seems like a great idea to me but that I feel wouldn’t work for me in practice. The context sensitivity of actions would drive me crazy. While it’s smart, I feel as though I prize consistency over cleverness in this regard since it makes it easier to make the usage of the commands second nature, but maybe I’d get used to the context sensitivity just the same.

countvajhula 5y ago
I'd love to understand your point of view a bit more. What do you mean by "context sensitivity"? Symex isn't context-sensitive in general and operates much like Vim/Evil in terms of consistency (e.g. you can define repeatable macros). Are you thinking of Lispy, which makes heavy use of context (and is certainly clever)? Re: the commands being second nature, that is very much a goal, and if there's something that could be better here for holdouts like yourself, I'd love to understand what that might be.
- b3morales 5y ago
  Not the original commenter, but I think I know what they were getting at. Basically a given command may do something "different" with regard to the bare text, depending on the start position in an S-exp. For example, in these two (where | is point) (foo bar |baz) vs. (foo bar |baz) moving "up", point will end up on the same line in the first and two lines up in the second. This, of course, is the point of structured editing, but it takes a bit of getting used to I think, and at first commands can seem sort of "unpredictable" or, as said "context sensitive" in a way that's different from more basic movement. (Though comparable to something like M-a for prose, of course.)
TeMPOraL 5y ago
There's not much, if any, context sensitivity IMO. But for it to click, you have to forget for a moment that you're working with a plaintext file, and imagine you're working with trees (that only happen to be serialized as text in front of you). The actions you're executing are defined in terms of operating on trees, not their text representation. The benefit of that, beyond cognitive and typing efficiency, is that (ideally) it should be impossible to enter a syntactically invalid state with structural editing commands alone. (I'm increasingly convinced that, while plaintext as a format is a great standard for many reasons, having all of our tools default to editing raw plaintext form severely hinders the whole industry.)

countvajhula 5y ago

I'd love to understand your point of view a bit more. What do you mean by "context sensitivity"? Symex isn't context-sensitive in general and operates much like Vim/Evil in terms of consistency (e.g. you can define repeatable macros). Are you thinking of Lispy, which makes heavy use of context (and is certainly clever)? Re: the commands being second nature, that is very much a goal, and if there's something that could be better here for holdouts like yourself, I'd love to understand what that might be.

b3morales 5y ago
Not the original commenter, but I think I know what they were getting at. Basically a given command may do something "different" with regard to the bare text, depending on the start position in an S-exp. For example, in these two (where | is point) (foo bar |baz) vs. (foo bar |baz) moving "up", point will end up on the same line in the first and two lines up in the second. This, of course, is the point of structured editing, but it takes a bit of getting used to I think, and at first commands can seem sort of "unpredictable" or, as said "context sensitive" in a way that's different from more basic movement. (Though comparable to something like M-a for prose, of course.)

TeMPOraL 5y ago

There's not much, if any, context sensitivity IMO. But for it to click, you have to forget for a moment that you're working with a plaintext file, and imagine you're working with trees (that only happen to be serialized as text in front of you). The actions you're executing are defined in terms of operating on trees, not their text representation. The benefit of that, beyond cognitive and typing efficiency, is that (ideally) it should be impossible to enter a syntactically invalid state with structural editing commands alone. (I'm increasingly convinced that, while plaintext as a format is a great standard for many reasons, having all of our tools default to editing raw plaintext form severely hinders the whole industry.)