VS Code And LSP

Lux editor support is provided by the lux-gmod extension launching the selected compiler as luxc lsp. The extension is intentionally thin: it starts the compiler language server, contributes grammar and commands, and displays server results. Lux module resolution, realm checks, import/export completion, hover, diagnostics, and GMod API intelligence come from the same compiler version used for builds.

Install

The extension package is Althurdinok.lux-gmod. During alpha development you can also build a local VSIX from the lsp/vscode-lux workspace:

cd lsp\vscode-lux
npm install
npm run compile
npm run package
code --install-extension (Get-ChildItem .\lux-gmod-*.vsix | Select-Object -First 1).FullName

The VSIX does not include a separate language server binary. Configure the compiler executable you want the editor to use, or make it available through the workspace or PATH:

{
  "lux.compiler.path": "C:\\Tools\\lux\\luxc.exe"
}

Server Resolution

The extension starts the server by running:

luxc lsp

The extension resolves luxc from:

  1. lux.compiler.path
  2. workspace .lux/bin/luxc
  3. user ~/.lux/bin/luxc
  4. LUXC environment variable
  5. luxc on PATH

Compiler Commands

Commands that build or update data use the same resolved luxc.

Useful commands:

  • Lux: Compile Current Project
  • Lux: Update Garry's Mod API Database
  • Lux: Format Document
  • Lux: Show Module Exports
  • Lux: Show Active Realm
  • Lux: Show GMod API Coverage

Editor Intelligence

The current server supports:

  • diagnostics from parser, resolver, formatter, module graph, realm checks, and imports
  • import source completion
  • import specifier completion filtered by exported names and active realm
  • export list completion from module-scope bindings
  • GMod API root/member completion
  • method completion from inferred receiver facts such as LocalPlayer() and vgui.Create("DButton")
  • hover for Lux bindings, exports, imports, cross-part definitions, imported module exports, known GMod APIs, hooks, and official docs
  • signature help for Lux functions, GMod functions, methods, and hook callbacks
  • argument count diagnostics for known Lux function calls
  • definition across files in a multi-part module and through imported module exports
  • semantic tokens for Lux syntax and known/unknown external symbols
  • formatting through the compiler formatter

Quick Fixes

Lux quick fixes come from compiler analysis and LSP server data:

  • add source-level extern
  • add package-level extern to lux.toml
  • wrap realm-specific code in client { ... } or server { ... }
  • narrow an invalid export realm
  • open official GMod documentation for realm mismatches
  • format the current document when formatter diagnostics are emitted

Unknown external symbols are never treated as shared-safe. They are tracked as UnknownExternal and reported according to target.gmod.realm.unknown_external.

Official GMod API Data

gmod-api-db is generated from the official Facepunch pagelist and per-page JSON. It contains document records for every official page and a structured API index for functions, hooks, classes, panels, constants, enums, and realms.

This is a release requirement, not a convenience cache: the bundled database must prove document_page_count == official_page_count, structured_page_count == api_candidate_count, fallback_page_count == 0, and failed_page_count == 0. Manual data is allowed only as test fixtures or traceable override patches after official generation.

The VS Code extension consumes this through luxc lsp; it does not maintain its own API table.