Paredit 25 released, after 8 years
paredit.org
paredit.org
Does Emacs just do it automatically?
I was looking for the equivalent of Prettier for Lisp/Scheme and didnt really find anything.
There are built in minor modes such as electric-indent-mode that indent automatically, but I personally use aggressive-indent-mode.
Even if you don't use VS Code/Clojure specifically, the "Action" names should be the same or similar with other Paredit extensions, so you can become familiar.
Best advise I have for learning Paredit is doing the same as you would if you were to learn Vim: Every time you think "How can I do X faster?" look up the way to do it and write it down on a cheatsheet. After a couple of times it'll become muscle memory.
I eventually adapted them so I could have relatively consistent keybindings across vim/emacs/VSCode/IntelliJ and the results are here:
https://github.com/fiddlerwoaroof/dotfiles/blob/b13240a42fa4...
If you understand the elisp keybinding notation, it’s possible to use the C-, ones in VSCode.
[1]http://danmidwood.com/content/2014/11/21/animated-paredit.ht...
I've since switched from Clojure to CL but kept the elisp scripts from CFBT replacing Cider with Slime.
I always thought Vim got out of my way as far as text editors go but Emacs really gets out of my way.
As with most things I do I learn just enough to do what it is I want to do. I don't go searching for new things until it becomes painfully obvious that a new way needs to be found.
With that said I've barely touched the surface for the power of emacs, paredit and slime.
One of the first lisps I used let you use a super-closing ] instead of umpteen ))).
That sort of made sense to me too.
If I was them I would've just embedded this video from "Emacs Rocks!":
https://www.youtube.com/watch?v=D6h5dFyyUX0
It shows how incredible paredit is.
(I'm not joking.)
It uses paredit (among others) for its low level functionality, but the vim-style modal interface allows you to manipulate the tree structure with single keystrokes in a precise and very expressive way. Keep in mind that you have to actively learn how to use it and it will feel awkward at first (similar to how vim feels for beginners), but I find the editing experience very pleasent and smooth after I got used to it.
Another thing I really like about it is that you can still switch to normal mode and it doesn’t get in your way like other plugins where I had to change my keybindings all the time because the amount of convenient shortcuts is still quite limited in the end. This modal switching to different editing contexts (or languages?) is something I feel should be explored much further.
When I last tried this, I felt like I was struggling against the mode's understanding of my syntax, more than it was assisting me. I didn't figure out how to "think" in its language. I want to know if I'm missing out on something wonderful, or if it's more of a "just another tool, don't worry about it".
I actually started enabling it when writing other languages (Python/C++) to see if it could do its magic there.
It turns out I've been using smartparens without realizing--just opened a file and checked the active modes to find out.
The keys I've learned are (using evil):
- [Visual mode] S -> surround by a pair
- [Visual mode] d <char> -> delete pair of <char>
- [Visual mode] c <c1> <c2> -> replace pair of <c1> with pair of <c2>
Those along with C-M-k to kill a sexp and % to go to the other end of a pair have been all I need for my work (the vast majority C/C++ and Python).
One thing I keep putting off is figuring out a way to jump to the opening/closing quotes. For those I still have to go medieval if there's any nesting.
Both the advantage and disadvantage of lisp are its lack of structure and paredit forcing you to keep your code intact really prevents a ton of issues just by having it on.
The only paredit shortcut I know is M-s to remove a set of parens.
That said I also use boon, which has some modal editing in particular a way to skip past an entire set of parens.
To GP: Why not enable it just for sake of keeping your parens balanced. Make sure you have a good way to discover commands like selectrum. And tada. Don’t have to learn it all right away.
Honestly I feel like those are enough for 90% of what I'm doing, and for now learning Paredit/infer is low on the priority list. Is it worth moving it up?
But Parinfer is particularly nice in that it makes not just editing easy, but also refactoring, which historically was one of my big annoyances with s-expressions.
Maybe Paredit has features for that too, but I didn't use it (the Vim port) long enough to learn its ins and outs.
Direct link to the Paredit section: https://susam.net/blog/lisp-in-vim.html#get-started-with-par...
This section introduces only the most basic features like electric returns, regathering, slurping, barfing, etc. For a complete documentation of all the features, it is worth entering :help paredit-keys directly in Vim. The help manual is not too long. Takes about 30 to 40 minutes to read through it and try some of the commands that look interesting.
But for paredit …
whilst it is useful when it is useful it is in the way when it is not. I find the best way is to use ; so to disable it and then edit and then re-enable it by erasing ; There is option to disable but need a few jkeysfroke. Hence ; all the time. The most annoying feature may I say.
Anyway just to say thanks thanks.
FWIW: after 20 years of Emacs I personally switched to VSCode a couple of years ago because I felt that in Emacs I was missing out on the LSP experience that VSCode provided in Rust, Typescript, Scala, etc. (I was using Eglot). In any case, there's a very nice Emacs emulation mode in VSCode
https://github.com/whitphx/vscode-emacs-mcx
which includes some paredit functionality courtesy of
https://robert.kra.hn/past-projects/paredit-js.html
and I'm working on porting my favorite paredit function, paredit-kill. Unfortunately that's the one where the paredit author left this comment in the code:
;;; Please do not try to understand this code unless you have a VERY
;;; good reason to do so. I gave up trying to figure it out well
;;; enough to explain it, long ago.I can see Paredit working somehow with the curly brace blocks of C, but how does it handle the significant whitespace of Python? Are indent and dedent handled as tokens?
Redefine the meaning of moving up, down, left or right by syntactic token. In Python up/down is either by block (try, if, etc.) or by s-exp ([], {}, etc.) which Emacs is already capable of doing.
By doing that you can effectively teach paredit a little bit about how the language works, as you're moving point around for it.
Note that my crude hack was never more than a prototype. Though it did work in more places than it ought to.
https://tree-sitter.github.io/tree-sitter/#available-parsers
here's a demo https://www.youtube.com/watch?v=2qsmF8HHskg
I use it on Doom Emacs, which configures everything for me.
We're generally so used to line-based editing, it may be frustrating but it's well worth the effort and once it clicks, you start to miss the features with other languages.
There's some truth in the old joke "If you think paredit is not for you then you need to become the kind of person that paredit is for."