1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
|
+++
description = "Cedit and paredit for structural editing"
title = "Cedit and Paredit"
date = 2014-08-04T07:10:14Z
[taxonomies]
tags = ["development", "emacs"]
+++
I recently discovered [cedit][], which provides some structural
commands for editing c-like languages. (See this
[Emacs Rocks! episode][e14] if you're not familiar with the concept:
it introduces [paredit][], a structural editing mode for lisps).
So, it deals with curly braces and semicolons, keeping things balanced
and correct as show in its [screencast][cedit-readme]. It mentions that it
integrates with [paredit][] rather than duplicating *all* its
functionality. After setting up cedit, I decided to try enabling
paredit alongside cedit and disabling autopair. Once I did,
however, I noticed an annoying formatting issue: If I were to type
`foo` and then `(`, paredit would format this as `foo ()`, which makes
sense, considering that paredit is written for lisps — s-expressions
are usually separated by spaces — but not so much for c-like languages.
I was thinking about disabling paredit and going back to autopair,
when I decided to look through the configuration variables for
paredit. Turns out it provides
`paredit-space-for-delimiter-predicates`, which is a list of functions
that control whether a space should be inserted. So, solving the
formatting issue turned out to be pretty simple:
```elisp
(defun ap/cedit-space-delimiter-p (endp delimiter)
"Don't insert a space before delimiters in c-style modes"
(not cedit-mode))
(add-to-list 'paredit-space-for-delimiter-predicates #'ap/cedit-space-delimiter-p)
```
Hopefully that saves someone some time if they try to use the two
together.
[cedit]: https://github.com/zk-phi/cedit
[cedit-readme]: https://github.com/zk-phi/cedit#readme
[e14]: http://emacsrocks.com/e14.html
[paredit]: http://www.emacswiki.org/emacs/ParEdit
|