`A` Does Not Respect The End Of Wikilinks

[uNyanda]

• Date: 2026-08-12
• Type: Bug
• Severity: Medium

Environment

• OS: Linux
• WM: Niri
• Compositor: Wayland
• Software version: 2.27.0

Description

The A Vim motion does not correctly position the cursor at the end of a wikilink.

In Vim, pressing A enters Insert mode at the end of the line. However, in ZenNotes, when a wikilink is the last element on the line, pressing A places the cursor before the closing ]] instead of after them.

For example:

This is a [[wikilink]]

When pressing A, the cursor should be positioned after the closing ]], but instead it is positioned before them.

Steps to reproduce

1. Create a note containing a wikilink at the end of a line.
2. Place the cursor on the line outside the wikilink.
3. Press A.

Expected Behaviour

A should enter Insert mode at the actual end of the line, after the closing ]].

Actual Behaviour

A enters Insert mode before the closing ]].

Additional Notes

While reproducing the bug, I found that when the cursor is inside the wikilink, pressing A correctly places the cursor after the closing ]]. The issue only occurs when the cursor is already outside the wikilink.

Screen Recording

[corpserot]

I can reproduce this on the feature/zennotes-cloud branch HEAD (6aa9239).

[adibhanna]

Fixed on the branch in 13cf184. Thanks for the precise report and gif, and thanks @corpserot for confirming it on the current branch, which mattered: the two builds were failing through two different mechanisms.

What was happening. With live preview, a line-ending wikilink renders as a chip, and the closing brackets are hidden while the cursor is outside the link (your "inside works" observation is exactly why: inside, the brackets are revealed and measurable). On 2.27.0, A finds the line end by resolving the rightmost visible glyph, which the hidden ]] pulls two short, and an internal step-back turns into three: your gif types wikilinjk because insert opened right before the k. On the current branch, the newer row measurement judged "same visual row" by midpoint closeness, and the chip sitting taller than the text beside it pushed the line-end midpoint past the tolerance, so the single-row line read as wrapped and A stopped at the chip's edge.

The fix. Row membership is now decided by vertical overlap, which a tall inline chip cannot fake, and when coordinates are unusable A and $ fall back to the logical line end, plain Vim's answer, instead of hunting for the rightmost visible pixel. Verified in the running app: A from anywhere on the line lands after the closing ]], $ rests on the closing ], and the wrapped-line behavior from the earlier fixes re-verified unchanged.

Ships in the next release with the rest of the wrapped-line and widget-measurement fixes.