Skip to main content

Language Features Overview

Flint gives you real Python (Jython) language intelligence for Ignition project scripts directly in VS Code — completion, hover, go-to-definition, references, diagnostics, and symbols — without requiring a running Designer. The default engine talks to your gateway over HTTP, so full language features work anywhere you have gateway access.

Prerequisites

The default Gateway LSP needs a configured gateway with an API token in flint.config.json and the Designer Bridge module installed on that gateway — no running Designer required. The legacy completion fallback works partially offline; its system.* completions require a connected Designer. See Connecting a Designer.

Two engines

Flint has two independent language-intelligence engines. You use one or the other, controlled by flint.languageServer.enabled (default: true).

Gateway LSP (default)Legacy completion (fallback)
Enabled byflint.languageServer.enabled: true (default)flint.languageServer.enabled: false
How it worksThe extension connects directly to the language server hosted by the Designer Bridge module on the gateway, over WebSocketVS Code completion provider merging local script indexing with Designer bridge responses
ProvidesCompletion, hover, definition, references, syntax diagnostics, document and workspace symbolsCompletion only
NeedsConfigured gateway + API token; Designer Bridge module v1.2.0+ on the gatewayWorks offline for local script completion; a connected Designer for system.* completions
ParserJython's ANTLR Python 2.7 parser with a per-project AST indexPrefix-string matching, regex script indexing, and Ignition stubs

The key difference for day-to-day work: the Gateway LSP delivers the full feature set with no Designer open. The legacy path exists for environments without gateway API access, and it only ever offers completion — no hover, definition, references, or diagnostics.

Feature matrix

FeatureGateway LSPLegacy completion
Completion (system.*, project scripts, local scope, keywords)Yes — position-awareYes — prefix-based; system.* needs a connected Designer
HoverYes — signature with parameter names (project code only)No
Go to definitionYes — within a file and across project scriptsNo
Find referencesYes — within the current file, best-effort identifier matchingNo
DiagnosticsYes — syntax errors only (source flint-jython)No
Document symbols / workspace symbolsYesNo
Signature helpNoNo

How the Gateway LSP connects

The language server runs inside the Designer Bridge module on the gateway. The extension opens a WebSocket to /system/flint-lsp on your selected gateway — authenticating with the API token and TLS settings from flint.config.json — and speaks the Language Server Protocol directly over that connection. All parsing and indexing happens on the gateway. If no gateway is configured, the gateway has no API token, or the gateway's module predates v1.2.0, the language server stays dormant; it starts automatically once configuration is in place, and reconnects when you change gateways or the gateway restarts.

If the gateway hosts a single project, the LSP selects it automatically; with multiple projects, set the project explicitly in your gateway configuration.

See Gateway LSP for setup and configuration details, and Completion for how the legacy engine's sources combine.

Ignition stubs

Independently of both engines, Flint downloads Ignition Python stubs from PyPI to power its own script indexing for legacy completion. The stubs feed Flint's completion engine — they are not wired into Pylance or python.analysis.extraPaths. See Ignition Stubs.

Limitations

Known limits
  • Python 2.7 only. Ignition scripts run on Jython, and the LSP parses with Jython's Python 2.7 grammar. Python 3 syntax is reported as a syntax error.
  • Diagnostics are syntax-only. Parse errors are flagged; there is no name resolution, type checking, or other semantic analysis.
  • Hover is limited. Signatures show parameter names only — no types, defaults, or docstrings — and there is no hover for system.* functions.
  • References are best-effort. Matching is intra-file and identifier-based, not full semantic resolution.
  • No Java-class completion. Members of Java classes (e.g. java.util.* imports) are not completed by either engine.
  • No tag-path completion. Neither engine completes tag paths inside strings.
  • No signature help in either engine.