Paredit changed the way I write Common Lisp, and I personally consider it a sort of killer feature of developer experience. Combined with canonical indentation of Lisp code (where every line can be indented in essentially just a single correct way, determined automatically by the editor), editing Lisp code actually becomes one of the most pleasurable of activities in programming. When you go back to editing Python, JavaScript, or C—even with a slick IDE—it just feels like a DX regression.
org mode with paredit for the lisp source blocks is a life changer! but it does highlight the deficiencies of other languages (and their editors) when one has to write/edit R, python, etc... Then again, being able to do so in the same file is a major win.
A revelation for me was doing a Racket course and seeing the style with the ending parens all on one line. Made so much more sense than matching up with the opening paren by indentation.
One of the first lisps I used let you use a super-closing ] instead of umpteen ))).
Emacs (and SLIME) do it automatically. I have some very, very light customization to change indentation for a couple cases (aligning keyword arguments, indenting MAKE-INSTANCE, etc).
In general, the answer is yes, but it depends on the major mode providing the functions necessary for code formatting. I'm not exactly sure what this looks like for Lisps, but I'd guess most of these functions are provided by SMIE (https://www.gnu.org/software/emacs/manual/html_node/elisp/SM...).
There are built in minor modes such as electric-indent-mode that indent automatically, but I personally use aggressive-indent-mode.
Is there a particular tutorial or method you followed to be fluent with Paredit. I like Lisp/Scheme but have never adopted any of the tools like Paredit or Parinfer but would be interested in doing so.
Seeing as you mix Lisp and Scheme together, I'm guessing you're not aiming for a specific language? If so, Calva (VS Code plugin for Clojure) has a visual guide for how to use Paredit via Calva: https://calva.io/paredit/
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.
Thanks! I’ll take a look at the Calva tutorial. I’m currently not really all in on a Lisp/Scheme, as you deduced, but Racket is my usual Lisp/Scheme goto. But I’m open to using Clojure to learn.
I started Emacs, Paredit and Clojure all at the same time. What helped me the most was Chapter 2 from _Clojure For The Brave and True_ (https://www.braveclojure.com/basic-emacs/). Knowing that the learning curve would be steep with emacs I cut myself a lot of slack.
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.
What made a difference for me was figuring out the right keybindings. The default keybindings in emacs weren’t very ergonomic and so I came up with a more convenient set of keybindings (for evil-mode, since I prefer vim-style editing). They follow a nice pattern on the keyboard and made a huge difference.
I eventually adapted them so I could have relatively consistent keybindings across vim/emacs/VSCode/IntelliJ and the results are here:
When I started using Paredit I found "The Animated Guide to Paredit"[1] very helpful. It basicaly demonastrates some of the most useful commands in short videos.
Wow! That looks pretty amazing. Makes we wish I used both a lisp and emacs... Does anyone know if there is anything similar that works for non-lispy languages (using syntax like do/end, {}, etc?) and in VSCode?
It's on the first line there "ParEdit (paredit.el) is a minor mode for performing structured editing of S-expression data. The typical example of this would be Lisp or Scheme source code." You'd have to known emacs nomenclature ( minor-mode ) and Lispy words ( S-expression )
I assume E: is for edit. I think GP was pointing out that the ParEdit website doesn't offer much in the way of explanation, and later found another site that did.
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.
Is it worth trying to make a serious effort with things like paredit, if you're already happy with default Emacs lisp modes? I feel like they're already overpowered.
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".
Paredit is so good that even after taking a break from Lisp for years, as soon as I opened up an .el file to do some Emacs customisation, the muscle memory was fully intact and I was able to perform structural edits without even thinking about which keys I pressed. I try not to write too much Lisp these days, because I inevitably become depressed at how clumsy it is to manipulate syntax in the languages I use more commonly.
I would consider myself a fairly unserious paredit user and I still think it's immensely useful. The things I use most of the time are really just barf, slurp and splice yet it makes so much more sense to me now to think of S-expressions structurally rather than just editing text.
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.
Same. I don’t even have shortcuts for paredit, I just M-X barf-forward- whatever (fuzzy find with selectrum) when I need it.
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.
I think it is worth it. Mastering it was one of the first times I felt like I had gained a programming power up. It's definitely a little awkward at first but if you keep at it, eventually the switch will flip and you'll wonder how you could've lived without it.
Paredit made a massive difference when I was writing Lisp. It does take some getting used to, but pretty sure it was a net positive after a week of use.
I actually started enabling it when writing other languages (Python/C++) to see if it could do its magic there.
In recent years, I have been spoiled by doom-emacs (and previously spacemacs). They have made everything work out of the box for me to such an extent that I mostly don't know what's active--I've just learned the right leader combination to get what I need done.
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.
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?
I use (Neo)Vim which only has minimal Lisp support built in. I started using Parinfer and it made a huge positive impact on my experience writing Lisp. It would probably be less impactful if I already had a good workflow and keyboard shortcuts that I liked.
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.
Do people have any tips on getting started with paredit in vim? I'm pretty happy with Parinfer but it sometimes makes working with other people's code painful...
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.
Thanks very much for your post once again. I just setup every lisp refer to yours even though I can recall every step you mentioned by now. Still such a great post.
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.
Same here. After getting used to the "automatic" way of editing and writing s-expressions, I can't believe something similar doesn't exists for the C-like code most people write today, but then I remember how much syntax all those languages really contain. Rust is like a trivia answer for "How much syntax could you possibly put into one language?".
Basic paredit operations work surprisingly well on C-like languages like Python. Try it! I think it does ok on Rust too. I'm thinking mainly of paredit-kill and navigating paired delimiters. A long time ago I collected together some tweaks for using it with Python etc here:
Hi Mickey, ah no -- you've done WAY more than me in this area! I had been meaning to try your combobulate package.
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
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?
I did something far cruder which is also how paredit itself works internally.
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.
No, I've never tried to make it do that. So in Python paredit-kill will not kill a function definition, whereas it would in a language that uses braces for function bodies.
Here's hoping that type of structured movement and editing will spread much wider now tree-sitter is merged into emacs master. Already quite a few parsers/grammars available for tree sitter:
Paredit is so good - completely changes how you edit. It was also the primary influence for making the Darklang editor a structured editor, though I confess it is not yet as good as paredit.
It took me a few attempts. What eventually worked was just getting used to one major feature of it, barfing and slurping, and after that it all clicked.
Yes. It's aimed at languages that use parentheses for structure - so it's _definitely_ helpful for Scheme.
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."
