Wire your editor

Connect `aontu lsp` to VS Code, Neovim, or any LSP client for diagnostics as you type.

Rendered from docs/how-to/wire-your-editor.md in the engine repository, where a correction belongs, and where the test suite executes every example on this page.

Both implementations serve the Language Server Protocol from the command itself, aontu lsp: unification problems as diagnostics while you type, with hover and completion beside them. Ready-made plugins for VS Code, Emacs and Vim/Neovim live in editors/, each a thin client that launches the server, with install steps in its README. The recipes below are for wiring a client yourself.

The facts every client needs: the command is aontu with the one argument lsp, the transport is stdio, and the document selector is the aontu language (.aon is the preferred extension, .aontu also works, .jsonic is retired). The server has no configuration options. The standalone aontu-lsp binary that earlier configurations name still ships and runs the same server.

Get the command any way the CLI guide lists: npm install -g aontu, a built binary, or go install. The two builds are interchangeable from a client’s point of view (running the server).

VS Code#

There is no published extension; the smallest path is a tiny custom extension whose activate starts the server with vscode-languageclient:

import { workspace, ExtensionContext } from 'vscode'
import { LanguageClient, TransportKind } from 'vscode-languageclient/node'

export function activate(_ctx: ExtensionContext) {
  const server = { command: 'aontu', args: ['lsp'], transport: TransportKind.stdio }
  const client = new LanguageClient(
    'aontu',
    'aontu',
    { run: server, debug: server },
    { documentSelector: [{ scheme: 'file', language: 'aontu' }] },
  )
  client.start()
}

From a checkout, use { module: '/abs/path/to/aontu/ts/bin/aontu-lsp.js', transport: TransportKind.stdio } for the TypeScript server, or command: '/abs/path/to/go/aontu' with the same args for a Go build.

Neovim (built-in LSP)#

vim.filetype.add({ extension = { aon = 'aontu', aontu = 'aontu' } })

vim.api.nvim_create_autocmd('FileType', {
  pattern = 'aontu',
  callback = function(args)
    vim.lsp.start({
      name = 'aontu',
      cmd = { 'aontu', 'lsp' },        -- or { 'node', '/abs/path/ts/bin/aontu-lsp.js' }
      root_dir = vim.fs.dirname(args.file),
    })
  end,
})

The filetype registration covers both extensions; the shipped vim plugin does the same and adds syntax highlighting.

Any LSP client#

Configure a server whose command is aontu with the argument lsp (or node …/aontu-lsp.js), transport stdio, document selector the aontu language / *.aon glob. No initialization options are required. One is available: hover provenance, which appends to each hover the contributions record aontu model why prints: ask for it and pay a second evaluation per hover, or leave it off and pay nothing (LSP hover provenance):

{ "initializationOptions": { "aontu": { "provenance": true } } }

What you will and will not see: the server flags contradictions, unresolved references and unknown constructs, and stays silent on schemas and partial documents: non-concrete is valid, so your half-written model does not light up red (how diagnostics are computed).

The full reference (architecture, both library APIs, the protocol surface) is the LSP page. The same contributions record the hover option shows is yours at the command line with explain a value.