Skip to content

v1.6.3

Choose a tag to compare

@github-actions github-actions released this 04 Sep 21:02
· 2 commits to main since this release
v1.6.3
e8efd95

A patch release: fixes and text-output changes only. No command, flag, JSON
field, schema_version, exit code, MSRV, or Nix interface changed.

Emacs Lisp formatting

paredit edit format --dialect elisp now agrees with Emacs' own
indent-region in the places it previously did not:

  • Special forms and nested special forms align on the body indentation Emacs
    produces, rather than on the generic call-argument rule.
  • Buffer and conditional forms (with-current-buffer, if, when, and
    friends) indent their bodies at the correct depth.
  • Registered indent properties are honoured even when the target width
    forces a break.
  • Escaped ? symbols survive formatting untouched.
  • A lambda parameter that happens to share a name with a special form stays
    inline instead of being indented as one.
  • Formatting an already-formatted Emacs Lisp file is idempotent.

Expect a diff on the first run over .el files that 1.6.2 formatted.

Blank lines in Emacs Lisp — a changed default

This is the one behaviour change automation should check. With
--max-blank-lines unset, Emacs Lisp now behaves as if --max-blank-lines 1
were given. Unset and 1 are not the same setting: unset discards the source's
blank lines and renders every top-level gap as exactly one, while 1 reads the
source's own count and clamps it.

Blank lines in source Unset (1.6.2, and 1.6.3 outside elisp) 1 (1.6.3 elisp default)
0, between top-level forms 1 — a blank line is inserted 0 — left adjacent
1 or more, inside a body 0 — blank lines are discarded 1 — preserved
2 or more, between top-level forms 1 1
;; source
(defun f ()
  (progn
    1

    2))
(defun g () 3)

1.6.2 deletes the blank line in f's body and inserts one between f and g;
1.6.3 does neither.

Only the default moved — the mechanism is dialect-independent, and
--max-blank-lines 1 produces exactly this output in every other dialect too.
An explicit --max-blank-lines, or format.blank-lines-max-consecutive in
paredit.toml, still wins.

There is no flag that restores 1.6.2's Emacs Lisp output, because the old
behaviour was "unset" and Emacs Lisp can no longer be unset.
--max-blank-lines 0 is the closest and is still not the same: it discards
blank lines, but it does not insert one between adjacent top-level forms.

paredit edit normalize-quotes

--all now rewrites every form the selector matches. The flag was ignored by
this one command, which refused a multi-match selector as ambiguous — and said
so by suggesting the flag that had just been passed.

Given (list (quote x) (quote y)) and
edit normalize-quotes --query '(quote ?x)' --all:

  • 1.6.2 exits 1 with Error [selection.ambiguous]: --query '(quote ?x)' matches 2 forms; pass --all to act on every match, or narrow the selector.
  • 1.6.3 exits 0 and prints (list 'x 'y).

This only turns a previous error into a successful rewrite; no invocation that
succeeded in 1.6.2 changes its output. If a wrapper script catches
selection.ambiguous from this command and retries without --all, that branch
is now unreachable.

paredit edit reindent-defun

A top-level definition that begins at a non-zero column is moved to column zero,
matching what indent-region does to a stray-indented top-level form. This one
is not Emacs Lisp-specific — it applies in every dialect. Spot-check before
running it across a tree that indents some top-level forms deliberately.

paredit inspect capabilities

Exits 0 when the consumer closes stdout early, in every output format:
paredit inspect capabilities --output json | head -5 no longer fails on the
broken pipe. Any || true wrapping this call to swallow that failure can go.

Install

nix run github:nerima-lisp/paredit-cli/v1.6.3 -- --help
nix profile install github:nerima-lisp/paredit-cli/v1.6.3
cargo install --git https://github.com/nerima-lisp/paredit-cli --tag v1.6.3 --locked