fix: editor [[-completion no longer opens on cursor navigation #9

Merged

fiatcode merged 2 commits from fix/editor-completer-nav into main

2026-06-16 14:30:34 +07:00

fiatcode commented

2026-06-16 14:29:34 +07:00

Owner

Summary

The in-app editor's [[ completion strip is meant to be a typing affordance, but refreshCompleter ran after every forwarded key — arrows, Home/End, PageUp/PageDown, and on file open. So moving the caret onto a pre-existing unclosed [[name (or opening a file that ends in one) spuriously popped the strip open, often with a "＋ Create" row.

Root cause: linkCompleter.refresh activated whenever the caret sat to the right of an unclosed [[ with no ]] ahead, regardless of what triggered the refresh. (The old code comment even falsely claimed it ran "after every textarea-mutating key.")

Fix: gate activation on an actual buffer mutation. refresh gained an allowOpen bool; EditorView.Update sets it by comparing ta.Value() before/after the key. Mount, accept, and PageUp/PageDown pass false. An already-open strip still updates and closes as you navigate; only an edit can open a closed one.

Found via reproduction harness, fixed with TDD (failing tests first), and given a code-quality review (approved).

Test Plan

go vet ./... && go test ./... green
New regression tests through the real Update/mount path: navigate onto unclosed [[ stays closed; opening a file ending in [[ stays closed; typing into an unclosed [[ after navigating opens; dismiss-then-navigate stays closed
linkCompleter unit test for the allowOpen gate (open-only-on-edit, update-and-close-on-nav)
All pre-existing editor/completion tests still pass

Ships in v1.4.0 (held release).

## Summary The in-app editor's `[[` completion strip is meant to be a **typing** affordance, but `refreshCompleter` ran after *every* forwarded key — arrows, `Home`/`End`, `PageUp`/`PageDown`, and on file open. So moving the caret onto a pre-existing unclosed `[[name` (or opening a file that ends in one) spuriously popped the strip open, often with a "＋ Create" row. **Root cause:** `linkCompleter.refresh` activated whenever the caret sat to the right of an unclosed `[[` with no `]]` ahead, regardless of what triggered the refresh. (The old code comment even falsely claimed it ran "after every textarea-*mutating* key.") **Fix:** gate *activation* on an actual buffer mutation. `refresh` gained an `allowOpen bool`; `EditorView.Update` sets it by comparing `ta.Value()` before/after the key. Mount, accept, and `PageUp`/`PageDown` pass `false`. An already-open strip still updates and closes as you navigate; only an edit can open a closed one. Found via reproduction harness, fixed with TDD (failing tests first), and given a code-quality review (approved). ## Test Plan - [x] `go vet ./... && go test ./...` green - [x] New regression tests through the real `Update`/mount path: navigate onto unclosed `[[` stays closed; opening a file ending in `[[` stays closed; typing into an unclosed `[[` after navigating opens; dismiss-then-navigate stays closed - [x] `linkCompleter` unit test for the `allowOpen` gate (open-only-on-edit, update-and-close-on-nav) - [x] All pre-existing editor/completion tests still pass Ships in v1.4.0 (held release).

fiatcode added 2 commits

2026-06-16 14:29:34 +07:00

fix: editor [[-completion no longer opens on cursor navigation 3f5395e491

The completion strip is a typing affordance, but refreshCompleter ran after
every forwarded key — including arrows, home/end, pgup/pgdn, and on file open —
so moving the caret onto an unclosed [[ (or opening a file ending in one) popped
the strip with a spurious '+ Create' row. Gate activation on an actual buffer
mutation: only an edit may transition the strip from closed to open; navigation
still updates or closes an already-open strip.

docs: changelog entry for editor completion-nav fix

CI / vet-and-test (pull_request) Successful in 30s

Details

cc6e459231