Features

This page provides an overview of the language server features that JETLS offers.

Screenshots on this page use VSCode (via the jetls-client extension), as its LSP UI is the de facto reference. The same features work in any supported editor, though the presentation may differ.^[error_lens]

Note

JETLS is under active development. This page is not exhaustive and is updated as features mature. For the current status of planned features, see the roadmap.

Overview

Diagnostic
- Syntax diagnostics
- Lowering diagnostics
- Inference diagnostics
Completion
- Global and local completion
- Method signature completion
- Keyword argument completion
- LaTeX and emoji completion
Signature help
Go to definition
Document link
Find references
Hover
Document highlight
Document and workspace symbol
Code lens
- Reference count
- TestRunner code lens
Inlay hint
- Block-end hints
Semantic tokens
Rename
Code actions
Formatting
TestRunner integration
Notebook support

Diagnostic

JETLS reports diagnostics from three analysis stages — syntax parsing, lowering, and type inference — covering everything from malformed input to deep type-level issues. Some diagnostics come with quick-fix code actions. See the Diagnostic reference for the full list of diagnostic codes and examples.

Syntax diagnostics

Parse errors detected by JuliaSyntax.jl.

Lowering diagnostics

Static analysis issues produced during lowering by JuliaLowering.jl — including undefined / unused bindings, unreachable code, scope ambiguities, and import-related issues.

Inference diagnostics

Type-level issues caught by JET.jl during type inference, such as non-existent field access, out-of-bounds indexing, method errors, and non-boolean conditions.

Completion

JETLS provides type-aware code completion with multiple modes.

Global and local completion

Completion for global symbols (functions, types, modules, constants) and local bindings. Global completion items include detailed kind information resolved lazily when a candidate is selected.

Method signature completion

Triggered inside a function call (after (, ,, or space). Compatible method signatures are suggested based on already-provided arguments. Selecting a candidate inserts remaining positional arguments as snippet placeholders with type annotations. Inferred return type and documentation are resolved lazily.

See [completion.method_signature] prepend_inference_result for the configuration option that shows the inferred return type inline.

Keyword argument completion

Triggered inside a function call at the keyword argument position (e.g. func(; |) or func(k|)). Available keyword arguments are suggested with = appended. Already-specified keywords are excluded.

LaTeX and emoji completion

Type \ to trigger LaTeX symbol completion (e.g. \alpha → α) or \: to trigger emoji completion (e.g. \:smile: → 😄), mirroring the Julia REPL.

Trigger	Example
LaTeX symbol (`\`)	$LaTeX completion$ $LaTeX completion$
Emoji (`\:`)

Signature help

Method signatures are displayed as you type function arguments. Methods are filtered based on the inferred types of already-provided arguments — e.g., typing sin(1, shows only methods compatible with an Int first argument.

Go to definition

Jump to where a symbol is defined. JETLS resolves method and module definitions, as well as local bindings.

JETLS also implements go to declaration (textDocument/declaration), which jumps to declaration sites (e.g., import/using, local x, or empty function foo end) when distinct from the definition, and falls back to go to definition otherwise.

Document link

Path strings inside include("...") and include_dependency("...") calls become clickable links that open the referenced file. The path must be a single non-interpolated string and resolve to an existing file relative to the current document's directory.

Find references

Find all references to a symbol across files analyzed together (e.g., a package and its included files). Both local and global bindings are supported. When the client requests includeDeclaration=false, method definitions of the target are excluded.

Hover

Hover over symbols to see documentation and source locations.

Binding kind	Description	Example
Global binding	Shows documentation from the binding's docstring along with its source location.
Local binding	Shows the binding's definition location within the enclosing scope.

Document highlight

Highlight all occurrences of the symbol at the cursor within the current file, distinguishing between writes (definitions, assignments) and reads (uses).

Document and workspace symbol

Symbol scope	Description	Example
Document symbol	An outline view of the current file, listing modules, functions, methods, structs, constants, etc.
Workspace symbol	Fuzzy-search across symbols in the whole workspace.

Code lens

JETLS surfaces actionable information inline above relevant code via code lenses.

Reference count

When code_lens.references is enabled, a reference count is displayed above each top-level symbol (functions, structs, constants, abstract/primitive types, modules). Clicking the lens dispatches the editor.action.showReferences command (a VSCode convention) carrying the pre-resolved reference locations. Clients that follow this convention open the references panel out of the box; clients that don't need a client-side handler — see the Neovim setup for an example.

TestRunner code lens

Run and re-run @testset blocks directly from the editor. See TestRunner code lens for details.

Inlay hint

Block-end hints

Label the construct that a long end keyword closes — module Foo, function foo, @testset "foo", and so on — to make navigation in long blocks easier. See [inlay_hint.block_end] for enable/disable and threshold configuration.

Semantic tokens

JETLS implements textDocument/semanticTokens to augment the editor's built-in syntactic highlighter (e.g. tree-sitter or TextMate grammar) with information that requires semantic analysis. Tokens for keywords, operators, literals, comments, and macros are left to the syntactic highlighter, which typically handles them well without semantic information.

Emitted token types:

parameter — function arguments
typeParameter — where clause type variables
variable — locally scoped names
jetls.unspecified — global bindings (function, type, module, variable etc.) whose concrete kind JETLS does not classify. Sending a custom (non-predefined) type leaves the syntactic highlighter's color in place while still allowing modifier styling (e.g. .declaration) to apply.^{[jetls_unspecified_styling]}

Modifiers:

declaration — explicit local x declarations
definition — assignments, function arguments, where bindings

How these tokens are rendered depends on the editor theme. In the screenshot below (VSCode with the Catppuccin theme), xs and factor are colored as parameter and T as typeParameter, while the locally bound total and x use the variable color. Identifiers carrying the definition modifier are rendered in bold, so the definition sites of xs, factor, T, total, and x stand out from their references.^{[semantic_tokens_customization]}

Both textDocument/semanticTokens/full and textDocument/semanticTokens/range requests are supported. Delta updates are not implemented.

Note

Because JETLS only emits identifier classifications and leaves keywords / operators / literals / comments / macros to the editor's syntactic highlighter, semantic tokens are only registered when the client advertises augmentsSyntaxTokens = true in its capabilities. Clients that do not declare this capability, or that explicitly set it to false, will not have JETLS's semantic tokens feature activated.

Rename

Rename local or global bindings across files analyzed together (e.g., a package and its included files).

When renaming a string literal that refers to a file path (e.g. in include("foo.jl")), JETLS also renames the file on disk.

Code actions

JETLS provides code actions for quick fixes and refactoring, including:

Prefix unused variables with _ (or delete the assignment entirely)
Remove unused imports
Sort import names
Delete unreachable code
Insert global / local declarations for ambiguous soft scope variables
Run a nearby @testset or @test case via TestRunner code actions

A few representative examples:

Code action	Triggered by	Example
Prefix unused variable with `_`	`lowering/unused-argument`
Insert `global` / `local` declaration	`lowering/ambiguous-soft-scope`
Sort import names	`lowering/unsorted-import-names`

error_lensSome screenshots show diagnostic messages rendered inline next to the affected line. This presentation is provided by the Error Lens VSCode extension, not by JETLS itself — JETLS reports the diagnostic information through standard LSP channels, and the inline rendering is up to the client.
jetls_unspecified_stylingDo not assign a foreground color or fontStyle to jetls.unspecified itself (e.g. "jetls.unspecified": "#abcdef") — doing so would override the syntactic highlighter's color, defeating the very reason we use a custom token type. Modifier-targeted rules (*.declaration, jetls.unspecified.declaration etc.) are the intended way to style these tokens.

semantic_tokens_customization

The semantic tokens screenshots use editor.semanticTokenColorCustomizations on top of Catppuccin to color typeParameter distinctly and to render tokens carrying the definition modifier in bold:

"editor.semanticTokenColorCustomizations": {
  "[Catppuccin Latte]": {
    "rules": {
      "typeParameter": "#fe640b",
      "*.definition": { "bold": true }
    }
  },
  "[Catppuccin Mocha]": {
    "rules": {
      "typeParameter": "#fab387",
      "*.definition": { "bold": true }
    }
  }
}