What completes at the caret

The language server published diagnostics and nothing else. It now answers what completes at a caret, what is under it, and where that is defined, from the same list the reference is printed from.

What landed

• Completion. physics2d:: gives that module's 66 functions and 48 constants. node.body2d. gives what acts on that component, plus the six a handle always answers. this. gives the script's exports() and pub fns.
• Hover and signature help. A function's signature, and the line the reference prints for it.
• Go-to-definition. ⌘B. A project pub fn opens its file at its line; engine API has no file, so it opens the Docs dock.
• A Docs dock. The reference, module by module, read from the running engine rather than a file, so a plugin's own module is in it.
• Formatting. balaur fmt ., with --check naming what would change and exiting 1. ⌥⇧F in the editor.
• Rename. ⌘⇧R, across the files a script's mod declarations reach, every match listed before anything is written.
• A VS Code extension. editors/code spawns balaur lsp, so it shows what the Script persona shows. Zed and Neovim get a recipe each.

Where the completions come from

• The engine's own record. 39 modules, 638 functions, 368 constants, as declared. The same list balaur api prints and the reference is built from.
• A lint keeps it complete. CI fails on a function with no doc line.

Rune's own server is not reusable

• Its completion is pub(super). The one public entry owns its stdin loop, and the feature pulls in tokio, syntect, handlebars and rust-embed.
• Two pieces came across. Unit::debug_info() lists a unit's functions, and rune::fmt costs nothing beyond alloc.
• One needed the fork. Context::iter_functions was pub(crate); opening it up is what completes "".len().

Semantic tokens, inlay hints and code actions are not planned. The scripting manual has the full list.