cx-tooling
vscode, neovim, tree-sitter, completions, syntax, the installer
Why reach for it
The editor knows the language because the language tells
it. cx-tooling is the editor and diagram surface: the VS Code
extension, the Neovim and Helix configuration, the tree-sitter
grammar, the shell completions, the TextMate syntax, the installer
scripts, the Linguist submission, the <cx-diagram> web component and
the repository template every component repository starts from — plus
the CX half of cx-stdlib/diagram, the one bundled module that left
the frozen standard library for the product that consumes it.
Three layers stack on the cx binary — a TextMate grammar for display
contexts, the language server for live editing, tree-sitter for
structure and injection — and the front door holds them to the
binary: the completions are checked against the CLI's own subcommand
and flag catalog, the grammars and the parity register against the
lexer and the language server, each a step of the front door that
reads this repository from its pin. A verb added to cx without its
completion is a failed step, not a stale editor. editors and cli
are the guide's pages.
The diagram renderer is a pure CX program: it renders a program's
image to Mermaid carrying the source as round-trip metadata, emits
DOT, splices the source into SVG and PNG, and recovers it from all
three; its rules table is a sealed value the completeness gate diffs
against the spec, the golden corpus and the grammar registry. Its V
half — the C ABI export, the goldens — stays with the language core,
so diagram is a two-repository module, like the others that
straddle a boundary (cli-diagram is the command surface).
What it gives you
One module of the standard library — pure, Ring 1 — bundled into the
build from the pin, its specification and corpus travelling with it;
it links to the reference page projected from its own documentation.
The editor surface ships as files, not a module: install it with the
scripts under tooling/install/.
This repository ships no bundled module of its own; what it gives you is above, and its links are below.
Try it
Render a one-node program to Mermaid and read the source back out of the rendering: the round trip is the contract — a diagram is a projection of the program, never a drawing beside it.
prog.cx
[?lib 'cx-stdlib/diagram' as=diagram]
[$diagram:extract-mermaid [$diagram:render-mermaid [greet] "[greet]" "min"]]
$ cx prog.cx
'[greet]'
Fixture diagram-001-render-mermaid in deps/cx-core-code/conformance/stdlib/diagram.cxd — replayed against this cx when the page was built.
Status
The tooling repository ships as an editor surface: its module is bundled into the build from the pin, and the front door's editor checks read the completions, grammars and parity register from the same checkout, so what the editor knows and what the binary does are graded together.
| fact | as the registry records it |
|---|---|
| ships as |
editor
|
| status | extracted |
| pinned at |
c919681fb
— the registry's at=; deps.cxd carries no row for it, so nothing of it is in the build |
| builds on | none recorded — the registry row carries no pins= column yet |
| built on by | nothing pins it yet |
| bundled modules | 0 |
cx-tooling plugs into: the repositories it builds on (left), the modules it ships (centre), the repositories that build on it (right) · drawn from registry/repos.cxd, deps.cxd and registry/modules.cxd when this page was builtLinks
- github.com/cx-home/cx-tooling — the repository
- README — what it is, how to install it, what it pins
- The front door pins nothing of this repository, so no checkout of it is in the tree this page was built from: the two links above are the registry's row, fetched by the site's external-link step and verified against no tree here; its specification and its corpus, where it keeps them, are its own.