Skip to content

zn v0.9.2: a second $ reaches the end of a wrapped line; ``` makes a code fence - #14

Merged
adibhanna merged 2 commits into
mainfrom
zn-0.9.2
Oct 22, 2026
Merged

adibhanna merged 2 commits into
mainfrom
zn-0.9.2

Conversation

@adibhanna

Copy link
Copy Markdown
Contributor

Two editor fixes reported on Discord by Scotty, released as v0.9.2.

  • A second $ on a wrapped line reaches the end of the line (ebb1fc9): with soft wrap on and vim.wrapped_line_motions = "display" (the default), $ stops at the end of the visible row, as the desktop editor does. Pressing $ again there now goes on to the end of the logical line, where nvim's $ lands; before, the second press did nothing. g$ and operators (d$) keep the visible row, and a counted $ and the "logical" setting are unchanged. The README and the in-app manual say how to reach the end.
  • **Typing makes a code fence instead of four backticks** (8ada218): auto pairs gave every backtick a closer, so became ```` with the cursor before the fourth and Enter split the line. A backtick right after another backtick now grows the run instead, so (orgo) stays as typed and Enter adds the closing fence below, as in the desktop editor. A single backtick still pairs.

Tests: go vet ./... and go test ./... pass locally, and the new engine and TUI tests fail on v0.9.1. darwin, linux and windows builds pass. Live in zn tui (tmux, 100 columns) on a 168-character line: $ landed on 3:88, $ again on 3:168, g$ on 3:88; v0.9.1 stayed on 3:88. Typing go then Enter opened the block with below the cursor; v0.9.1 left ```` and split it.

How to test locally

go build -o ./zn ./cmd/zn
./zn tui

Open a note with a line long enough to wrap, put the cursor on it in normal mode and press $ twice: the first press ends the visible row, the second reaches the end of the line. Then press o, type go and Enter: the closing appears on the line below the cursor.

With soft wrap on and vim.wrapped_line_motions = "display" (the default),
a bare `$` stops at the end of the row the cursor is on, as the desktop
editor does (#536 there). That part is deliberate. But pressing `$` again
on that row found the same row and stayed put, so the true end of a long
line was out of reach without `A<Esc>` or switching to logical motions.
Reported on Discord by Scotty, who expected nvim's `$`, or at least a
second press that gets there.

Now a bare `$` that starts on the last character of a row that is not the
line's last goes on to the end of the logical line. The first press still
ends the visible row; `g$` stays the row motion and never runs past it,
and operators keep the row too, so `d$` still deletes only what the user
can see. A counted `$` and the "logical" setting behave as before.

Engine tests cover the first, second and third press, `g$`, `d$` and
`v$$`. The README's wrapped-line sentence and the manual's motion list say
how to reach the end. Live in zn tui on a 168-column line: `$` landed on
3:88, `$` again on 3:168, and `g$` on 3:88.
With auto pairs on, the editor gave every backtick a closing partner. The
first backtick paired, the second stepped over its partner, and the third
paired again, so ``` became ```` with the cursor before the fourth. Enter
then split that line into ``` and a stray backtick, and the fence snippet
that closes a code block on Enter never got its chance. Reported on
Discord by Scotty.

A backtick typed right after another backtick now grows the run instead
of opening a pair, so ``` (and ```go) stays as typed, and Enter adds the
closing fence below with the cursor inside the block, as in the desktop
editor. A single backtick still pairs, so `ls` types as before.

The desktop never pairs backticks; the terminal keeps its inline pairing
and only stops pairing inside a run.

Tests: engine cases for ```, ```go and an inline span, and a TUI test that
types ```go and Enter through the App's key path. Both failed before this
change (```go` and ````). Live in zn tui: ```go then Enter opened the
block with ``` below it, and `ls` still paired.
@adibhanna
adibhanna merged commit 8ada218 into main Oct 22, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant