Emacs Rocks! Episode 14: Paredit

For those not familiar with Emacs, IntelliJ IDEA with La Clojure is also an okay choice. I use IDEA for Python, Java and Scala; and still switch to Emacs when I code in Clojure. The reason is that Emacs has really strong toolset for LISP, where many of the features are missing from other environments, or implemented partially. Slime/swank (nrepl replaces it, but I'm just slowly transitioning to it), provides code completion, documentation lookup, REPL, macro expansion and even live code updates on a running application; which can be a bit of a pain to setup on other editors. And the integration in Emacs is really great, as the repl buffer is really just a text buffer, the same as the one you are coding in. But the biggest reason for me to code LISP in Emacs is paredit. It really makes all the trouble with balancing parenthesis and moving around the sexps really easy. It might seem counter intuitive and a bit troublesome at first, but I really recommend you to try it. For a short and enthusiastic video on paredit, see [VIDEO] -- and maybe the other Emacs Rocks! videos to learn more about modern Emacs.

I'll be honest with you: I'm maybe not the one to give proper advice on paredit. I'm using C# on my day job, and as such have no use for paredit (I do use ViEmu for VS though, which makes VS bearable) for most of my programming tasks. Also, I've never done anything in clojure. I expect it to be a similar experience to CL, but the different types of parenthesis might have an effect on using paredit efficiently. That said, I found that the following mapping really makes a huge difference when working with sexps & evil-mode: C-l: paredit-forward-slurp-sexp C-k: paredit-backward-barf-sexp C-j: paredit-backward-slurp-sexp C-h: paredit-forward-barf-sexp Your mileage may vary, of course. I mapped it this way because my fingers dictated it, and it plays well with vim/evil. As to how to actually use these commands: Try them out on a few sexps, it'll be clear to you pretty soon. Also be sure to check out Emacs Rocks! ep14 ( [VIDEO] ), it's well worth the 3:40. I actually find learning paredit to be very similar to learning vim: You start with almost nothing (maybe hjkl in vim, but even that takes a while to get used to), and slowly add new tricks to your tool belt. Also like with vim, everyone has their own style of using the tools. Of course, there's a ton of other things in paredit which can improve your efficiency which I haven't added to my muscle-memory yet. It's just that I found barfing/slurping to be the most bang for the buck, so I added them first.

There's a structured editing mode for Emacs called Paredit, to use for s-expression languages like Lisp, Racket, Clojure. Since the AST for such languages is s-expressions, and some people struggle with parens, this is an interesting "fun size" example of editing the AST. The thing is, paredit is quite challenging for most people to adopt, due to what you mentioned about the "flow" they've already learned. Magnar Sveen has a great video about this at [VIDEO] Best quote: "If you think paredit is not for you, then you need to become the kind of person that paredit is for." EDIT: To clarify, Magnar is quoting technomancy a.k.a. Phil Hagelberg.

If you pair a majority of the time, sure, make a standardized workstation with your team. My team uses viemu in VS, which the rest of our office detests, but hey, we are the ones pairing 99% of the time. When I am not pairing for the majority, I setup my machine to my tastes, and simply install a "default" editor for the few times someone else actually needs to type on my machine. Emacs and IDEA both have good ways to revert everything to defaults temporarily. I do not believe, however, that a perfectly customized setup has only small gains. For example, consider two tools that I have never seen as defaults in any editor or IDE: rainbow parens/brackets and paredit mode. Rainbow parens just highlights pairs: [LINK] And here is a short minute paredit mode explanation: [VIDEO] When actually editing code, those two tools save me several hundred keystrokes an hour. And those are just the first two tools I thought to use as an example out of the entire toolbox that is emacs. If I was to now give up just those two tools, I would be sentencing myself to the mental equivalent of tying five pound weights to my legs for the marathon that is the rest of my programming career. Why would I intentionally require myself to type more keys per hour to do the same editing, rather than just learning a faster way to edit? This is, obviously, also my argument for learning the vim editing system (which I also use in emacs).

Emacs's structured editing, in the style of paredit[1], sounds very similar to a text-based version of syntax-directed editing (SDE). Designed for Lisp and S-expressions, it's a system that lets you edit and navigate around nested expressions at a syntactic rather than textual language. As you type, the correct level of nesting is maintained and there are commands for moving and editing code in terms of s-expressions rather than characters. In practice, it's very easy to start using and very powerful... but requires using Lisp. It'll seem odd if you're not regularly a Lisp user. Happily, this idea can generalize well enough to distinctly non-Lisp languages. Structured Haskell mode[2] does this for Haskell, which has a less regular and sparser syntax than s-expressions. The documentation has a bunch of handy animations showing the various features, giving you an idea of how it works without having to install it yourself. This doesn't address the meat of the blog post—composing languages and grammars by taking advantage of structured editing—but it shows that the necessary foundation is possible with a perfectly normal text editor. It would be interesting to see if some of the ideas from Eco could be added to structured editing modes like this without requiring you to use an external, self-contained editor. [1]: [LINK] [2]: [LINK] Also, here's a great video of Paredit in action: [VIDEO]

The parentheses end up serving as a tool to speed up the development process with tool like paredit. You end up manipulating the "tree" of code vs the characters on a line. Check this out: [VIDEO]

not op but for me structured editing is one of the biggest pluses when it comes to editing lisp code. here is a good example of what i mean [0]. btw autolisp standard formating is kind of an anti-example of good lisp formating. in emacs lots of excellent tools exist to make parantheses an extremely helpful feature [1] [0] [VIDEO] [1] [LINK]

Yeah... a couple GIFs would. If I was them I would've just embedded this video from "Emacs Rocks!": [VIDEO] It shows how incredible paredit is.