What do you think about adding some evil-cleverparens behaviors?

[corasaurus-hex]

TL;DR:

• move to the next/previous open/closing parens/bracket/curly-brace regardless of the depth of the form
• refuse to unbalance open/closing parens/bracket/curly-brace when things are deleted

The Longer Version

evil-cleverparens is an emacs mode for making lisps easier to work with when using evil (vim-mode for emacs). It has some very neat behaviors that I think are desirable.

Starting with movements, evil-cleverparens has a form navigation that is really neat and doesn't exist in paredit. Namely that can jump to the next/previous open/closing parens/bracket/curly-brace regardless of the depth of the form. Here's a video demonstrating it. Here's the elisp code that performs it.

The other neat ability it has is it can refuse to unbalance parens when deleting. Meaning you can delete a whole line but it won't ever unbalance parens even if those parens are selected. Here's a video demonstrating it.

The common thread with these behaviors is they make you have to think less, meaning navigation and editing becomes simpler for the user. No need to think about if a sexp is up or down in order to navigate to it, just keep hitting { or [ or ] or } until you're at it. No need to be careful about unbalancing parens, just delete the line and the editor will keep it balanced.

Anyways, this is just a feature request for something I'm missing from emacs. What do you think?

[PEZ]

I like it. VS Code does not allow shortcuts with brackets, but we can leave the commands unbound and then VIM extension users can bind them (assuming things can be bound to whatever with that extension).

[corasaurus-hex]

Awesome! I'd love that. 💜

[corasaurus-hex]

Any advice on implementing this? I'd like to give it a shot.

[corasaurus-hex]

I suppose there are really (at least) two features here.

1. moving to the next/previous open/closing parens/bracket/curly-brace regardless of the depth of the form
2. refusing to unbalance open/closing parens/bracket/curly-brace when things are deleted

It feels like 2 would be the more difficult of the the features.

[riotrah]

Gosh I'd love the second feature. It's kinda parinfer-y in terms of how ergonomic it is haha

[corasaurus-hex]

right?? it's so amazing. paired with vim keybindings where you can just hit dd to delete a line it's soooooo clean

[riotrah]

Also:

1. Dumb nitpick from me: Consider editing the description body with your updated numbered breakdown list above - makes it easier to grok perhaps? idk
2. Do the recent forwardOrUpSexp etc scratch the itch of task 1?
3. It might be interesting or worthwhile to consider how diff people feel about that feature, and how to expose its configurability, and whether it's default or not. 4. For example, I have coworkers who actually dislike that Paredit is on by default and that they don't really get why it hijacks most of their configured keybindings, esp if they're new to Clojure and thinking about code structurally vs line-based. More relevantly, one of the most frequent complaints is Calva not deleting parens when they press backspace etc lol. 5. For such users, complete inability to remove parens might drive them absolutely mad 6. And personally, I like the idiot-proofness of this feature (i sure need it lol), but I also wonder what the best ergonomics would be to keep it idiot-proof but also allow at-will, opt-in (or -out I guess) purposeful deletion of parens 7. Ie, the last thing I want to do to selectively keep or delete parens is to click on the paredit toggle at the bottom or something, or remember some toggle keybinding (and remember to re-toggle it when I'm done), or to have to pull up the command palette etc.

What are your thoughts, @corasaurus-hex?

[corasaurus-hex]

1. Done! 2. Nope! Moving forward or backward may actually go down into forms. For example (|a {:b ["c" {'d 5}]} => cursor.forwardToNextClosingCharacter() => (a {:b ["c" {'d 5|}]}. It essentially doesn't care about depth and only cares about finding the next token with the semantic meaning of "closing character". It might be nice to include quotes as a closing character, too, so: (|a {:b ["c" {'d 5}]} => cursor.forwardToNextClosingCharacter() => (a {:b ["c|" {'d 5}]} 3-5. I could definitely see that, and I'd lobby for it to be optional. The behavior drives me up a wall sometimes and I generally like it so I totally understand. 6. Maybe it could be a separate command, like "deleteLineWhilePreservingClosingCharacters", and if the line both the opening and the closing character it gets deleted.

I like the idea of "power features" being off by default and introducing them one at a time and only when the user wants them.

[riotrah]

1. Thanks!
2. Ohhhh right on makes sense - I would use that. I currently use the vim nav row + option for (back, back down, forward down, forward, with u and i being back up and forward up respectively. I could see having your suggested ones at y & o or replace the exist back/forward! 3-5. Right on
3. Hmm how about if you select just a form boundary char/paren and then delete, then do delete, otherwise if a selection simply contains the char, then delete the rest, preserving the char?