Libraries like this are the most emacsy because the whole point of emacs is that it isn't just a good editor, but a platform/language for building good editors.
The introductory paragraph in the "Editing" section of the post explains the relationship to evil. Reproduced here for convenience:
"Symex’s editing style is essentially Vim-like. While Vim’s Normal mode can be considered a Domain Specific Language for text editing in general, it has the following drawbacks when it comes to editing symexes: (1) it doesn’t have an appropriate noun to refer to symexes (e.g. it only has “words,” “lines,” “paragraphs,” etc.), and (2) the nouns it has are for the most part irrelevant when editing symexes. Thus, it isn’t exactly the right language to use. Symex.el attempts to be “the right language” here by supporting just a single noun — symexes — which, by virtue of its singularity, need not ever be stated and is implicit in every action[2]. But aside from this, Symex mimics Normal mode idioms and conventions. Therefore, a lot of these usage patterns should be very familiar from Vim/Evil even though they aren’t the same — they are the same ideas applied to symexes (along with other symex-specific ideas)."
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.
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.
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.)
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.)
You're welcome to cripple yourself (and you'd be in illustrious company -- just about every famous name in Emacs's history has suffered severe RSI); I was just trying to answer your original question.
I don't think fame has anything to do with it, but for what it's worth, I've been using emacs for over 25 years and have never suffered from any form os RSI.
I don't feel crippled, by the way. But since I like keeping an open mind, if you have any actual arguments, please feel free to share.
In the mean time, if you're also open, I recommend checking out some counter arguments, for instance in the work of Larry Tessler.
It was definitely a surprise to me when I learned some time ago that "modelessness" was considered an innovation when it was developed, since editors before that (I assume) were all modal!
But I don't think modal/modeless is either/or. It can be (and I personally use) both.
Thanks for linking that; I've stumbled across it a while ago but forgotten about it. I just took a closer look, and I want to flag it for attention for two reasons:
1) It's amazing how a bunch of well-thought-out rules can produce complex, powerful and consistent behavior. Here, we have basic structural editing, enforcing structural correctness, and Python-like "structure by indentation" editing, all with no hotkeys other than one to switch between "indent mode" (you control the indentation, parinfer controls parens) and "paren mode" (you control the parens, parinfer controls indentation).
2) The page is a stellar example of documenting interactive functionality. It starts with an animated demonstration up front, continues with explaining the value proposition, then gently introduces background information necessary to fully understand the value proposition, explains the high-level abstractions behind the product, and ends with detailed usage examples. Everything that can involves an animated example - but it's not just an animation; all those textboxes are editable, so you can interrupt the animation to test the functionality live.
2a) On that last note, it was a brilliant decision by the author to build parinfer around formalized principles and a reference implementation "in straightforward, imperative JavaScript, optimized for speed and designed to be easy to port to other languages", with "a test suite which is also designed to be easy to port with all test cases represented in JSON files". This is why it took no extra work to provide interactive demos on the webpage, and it ensures the product - which is really more of a concept than an artifact - can easily spread.
I think it's worth learning from the author, even if one isn't interested in Lisp or modding their editor.
As an evil-mode user who switches between editing python and lisp semi-regularly I find adjust-parens with << and >> bound to adjust-parens indent/dedent functions to be the least harmful to my muscle memory.
This is the mode that made the whole structural editing stick for me. Tried paredit and then lispy but never got the hang of it. With this one I find that I try to use it all the time even in modes where I do not have it set up.
29 comments
[ 2.8 ms ] story [ 90.5 ms ] threadhttps://github.com/countvajhula/symex.el#introduction
Libraries like this are the most emacsy because the whole point of emacs is that it isn't just a good editor, but a platform/language for building good editors.
"Symex’s editing style is essentially Vim-like. While Vim’s Normal mode can be considered a Domain Specific Language for text editing in general, it has the following drawbacks when it comes to editing symexes: (1) it doesn’t have an appropriate noun to refer to symexes (e.g. it only has “words,” “lines,” “paragraphs,” etc.), and (2) the nouns it has are for the most part irrelevant when editing symexes. Thus, it isn’t exactly the right language to use. Symex.el attempts to be “the right language” here by supporting just a single noun — symexes — which, by virtue of its singularity, need not ever be stated and is implicit in every action[2]. But aside from this, Symex mimics Normal mode idioms and conventions. Therefore, a lot of these usage patterns should be very familiar from Vim/Evil even though they aren’t the same — they are the same ideas applied to symexes (along with other symex-specific ideas)."
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.)
(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.)
My editing habits are too deeply ingrained. Past attempts to switch all failed.
Instead I'll probably just use the good ideas from this package and adapt them to my own config. That's why I use emacs.
[citation needed]
I don't feel crippled, by the way. But since I like keeping an open mind, if you have any actual arguments, please feel free to share.
In the mean time, if you're also open, I recommend checking out some counter arguments, for instance in the work of Larry Tessler.
But I don't think modal/modeless is either/or. It can be (and I personally use) both.
[1] https://shaunlebron.github.io/parinfer/
1) It's amazing how a bunch of well-thought-out rules can produce complex, powerful and consistent behavior. Here, we have basic structural editing, enforcing structural correctness, and Python-like "structure by indentation" editing, all with no hotkeys other than one to switch between "indent mode" (you control the indentation, parinfer controls parens) and "paren mode" (you control the parens, parinfer controls indentation).
2) The page is a stellar example of documenting interactive functionality. It starts with an animated demonstration up front, continues with explaining the value proposition, then gently introduces background information necessary to fully understand the value proposition, explains the high-level abstractions behind the product, and ends with detailed usage examples. Everything that can involves an animated example - but it's not just an animation; all those textboxes are editable, so you can interrupt the animation to test the functionality live.
2a) On that last note, it was a brilliant decision by the author to build parinfer around formalized principles and a reference implementation "in straightforward, imperative JavaScript, optimized for speed and designed to be easy to port to other languages", with "a test suite which is also designed to be easy to port with all test cases represented in JSON files". This is why it took no extra work to provide interactive demos on the webpage, and it ensures the product - which is really more of a concept than an artifact - can easily spread.
I think it's worth learning from the author, even if one isn't interested in Lisp or modding their editor.