Developer Roundtable: ParEdit

What in the world is ParEdit?

Here is the “explain it to me like I’m 5” version:
“ParEdit is like a helpful assistant for editing code that uses a lot of parentheses (like in math or some programming languages). It makes sure you never accidentally mess up your parentheses, like leaving one off or putting one in the wrong place. It keeps your code neat and tidy, even if you move or change things. It’s perfect if you work with code that has lots of nested parts and want to avoid the frustration of breaking the structure.”

And if you want a more developer-centric explanation of ParEdit:
“ParEdit is a minor mode in Emacs designed for structured editing of S-expressions, commonly used in Lisp-like programming languages. It helps manage parentheses and other paired delimiters, ensuring that the structure of your code remains syntactically correct as you edit. ParEdit provides commands for navigating, slurping, barfing, and manipulating expressions without accidentally breaking the code’s structure. It’s especially useful for Lisp programmers who work extensively with nested parentheses.”

Casey introduced this discussion at the developer roundtable to explore different mental models of text editors. He outlined three primary models:

1. Character and Line-Based Editing

Most people are familiar with this type of editing. It’s what happens when you type in text boxes or work on a Microsoft Word document. You have text, a cursor, and you can move around, editing characters and lines directly. Everything is immediate and visual—when you make a change, you see it instantly. This is the foundational model of text editing.

2. Text Objects

Vim introduces this concept, allowing you to operate on larger structures instead of individual characters or lines. For instance:

• If you want to delete an entire paragraph, you can use the command dap (Delete Around Paragraph).
• This approach empowers you to work efficiently with objects beyond simple text, like entire paragraphs or blocks of code.

3. Structural Editing

This model builds on the notion of text objects and tailors it specifically for code. It acknowledges the hierarchical, tree-like structure of code and enables operations that respect this arrangement. For example:

• If you have several numbers and want to enclose them in a list, you can use a command to surround the next expression with delimiters.
• You can also “slurp” or “barf” elements in and out of delimiters. Pressing a single key lets you slurp elements into a delimiter or barf them out (think of it as shifting or unshifting elements). This feature allows for moving and rearranging code seamlessly.
  Before Slurping (forward slurp):

(foo (bar) baz)

You place your cursor inside (bar) and slurp forward, which grabs baz into the expression. After Slurping:

(foo (bar baz))

“Barfing” is the opposite, it expels an expression from inside a set of parentheses.

Before Barfing (forward barf):

(foo (bar baz quux))

With your cursor inside the list (bar baz quux), you do a forward barf, pushing out quux:

After Barfing:

(foo (bar baz) quux)

Max shared his experience with structural editing, emphasizing how concepts like slurping, barfing, and raising were difficult to learn at first. However, once he mastered them, he missed these features when working outside Clojure.

The roundtable then explored the potential of adapting these powerful editing paradigms to other programming languages. While some features seem universal, there are challenges, like losing control over syntax precision during transformations.

Yossef added his perspective on Vim’s editing model, focusing on motions rather than text objects. He described it as combining verbs and objects, such as “to the next instance of this character” or “to the end of this line,” highlighting a motion-driven approach.

Chris made a compelling observation: all these models ultimately break down to Regex operations. However, newer modes that integrate with the language parser enable smarter actions. For instance, you can delete a variable even if it looks like a string, as the editor distinguishes syntax through parser integration.

The rest of the discussion centered on different editors people have used, why they made the switch, and what features they missed or appreciated in new environments.

Enjoyed this content? Join our developer roundtable, we meet every other Friday from 10:30 - 11:30 am CT. Hope to see you there!

If you’re looking for a team to help you discover the right thing to build and help you build it, get in touch.