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 flint-lsp-proxy language server, bundled with the extension, connects to the gateway's headless Flint API over HTTPVS 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 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 extension launches the bundled flint-lsp-proxy language server and passes it the URL, API token, and TLS settings of your selected gateway from flint.config.json. The proxy translates LSP requests into calls against the gateway-scope Flint API, where the actual parsing and indexing runs. If no gateway is configured or the gateway has no API token, the language server stays dormant; it starts automatically once configuration is in place, and restarts when you change gateways.

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

The setting flint.languageServer.proxyPath is an advanced override for pointing at an external proxy binary — you do not need it for normal use.

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.