LSP support

The current implementation of LSP4IJ does not yet fully adhere to the LSP (Language Server Protocol) specification. This section provides an overview of the supported LSP features for IntelliJ:

Base support

Current state of Base protocol support:

✅ $/cancelRequest.
✅ $/progress (see implementation details)

Text Document Synchronization

Current state of Text Document Synchronization support:

✅ textDocument/didOpen.
✅ textDocument/didChange.
✅ textDocument/didClose.
✅ textDocument/didSave.
❌ textDocument/willSave.
❌ textDocument/willSaveWaitUntil.

Notebooks are not supported.

Language Features

Current state of Language Features support:

✅ textDocument/definition (see implementation details)
✅ textDocument/documentHighlight (see implementation details)
✅ textDocument/publishDiagnostics (see implementation details)
✅ textDocument/documentLink (see implementation details)
❌ documentLink/resolve.
✅ textDocument/hover (see implementation details)
✅ textDocument/codeLens (see implementation details)
✅ codeLens/resolve
✅ workspace/codeLens/refresh
✅ textDocument/inlayHint (see implementation details)
❌ inlayHint/resolve
✅ workspace/inlayHint/refresh
✅ textDocument/completion (see implementation details)
✅ completionItem/resolve (see implementation details)
✅ textDocument/signatureHelp (see implementation details)
✅ textDocument/publishDiagnostics (see implementation details)
✅ textDocument/codeAction (see implementation details)
✅ codeAction/resolve
✅ textDocument/documentColor (see implementation details)
❌ textDocument/colorPresentation.
✅ textDocument/declaration (see implementation details)
✅ textDocument/typeDefinition (see implementation details)
✅ textDocument/implementation (see implementation details)
✅ textDocument/references (see implementation details)
✅ textDocument/prepareCallHierarchy (see implementation details)
✅ textDocument/incomingCalls.
✅ textDocument/outgoingCalls.
✅ textDocument/prepareTypeHierarchy (see implementation details)
✅ typeHierarchy/subtypes.
✅ typeHierarchy/supertypes.
✅ textDocument/foldingRange (see implementation details)
✅ textDocument/selectionRange (see implementation details)
✅ textDocument/documentSymbol (see implementation details)
✅ textDocument/semanticTokens (experimental) (see implementation details)
❌ textDocument/inlineValue.
❌ workspace/inlineValue/refresh.
❌ textDocument/moniker.
❌ textDocument/pullDiagnostics.
✅ textDocument/formatting (see implementation details)
✅ textDocument/rangeFormatting (see implementation details).
❌ textDocument/onTypeFormatting.
✅ textDocument/prepareRename.
✅ textDocument/rename (see implementation details).
❌ textDocument/linkedEditingRange.

Workspace Features

Current state of Workspace Features support:

✅ workspace/didChangeWatchedFiles.
✅ workspace/executeCommand.
✅ workspace/applyEdit.
✅ workspace/symbol (see implementation details)
❌ workspace/symbolResolve.
✅ workspace/configuration (see implementation details)
❌ workspace/workspaceFolders.
❌ workspace/didChangeWorkspaceFolders.
❌ workspace/willCreateFiles.
❌ workspace/didCreateFiles.
✅ workspace/willRenameFiles.
✅ workspace/didRenameFiles.
❌ workspace/willDeleteFiles.
❌ workspace/didDeleteFiles.

Window Features

Current state of Window Features support

✅ window/showMessage. (see implementation details)
✅ window/showMessageRequest (see implementation details)
✅ window/logMessage (see implementation details)
✅ window/showDocument.
❌ telemetry/event.

Implementation details

Progress support

$/progress is implemented with Background Tasks.

Here a sample with Eclipse JDT Language Server:

Go to Definition

textDocument/definition is implemented via the
gotoDeclarationHandler extension point. As this extension point supports any language, it works out-of-the-box.

It is also called via Find Usages to show definitions.

References

The textDocument/references is consumed with:

the Navigate / LSP Reference(s) global menu.
or with the Go To/ LSP Reference(s) editor menu.

This menu action either opens the reference in a popup or navigates to the reference if there are several references:

textDocument/references is used also via Find Usages to show references.

Implementation

The textDocument/implementation is consumed with:

the Navigate / LSP Implementation(s) global menu.
or with the Go To/ LSP Implementation(s) editor menu.

This menu action either opens the implementation in a popup or navigates to the implementation if there are several implementations:

textDocument/implementation is also used via Find Usages to show implementations.

Type definition

The textDocument/typeDefinition is consumed with:

the Navigate / LSP Type Definition(s) global menu.
or with the Go To/ Type Definition(s) editor menu.

This menu action either opens the type definition in a popup or navigates to the type definition if there are several type definitions:

textDocument/typeDefinition is also used via Find Usages to show Type definitions.

Declaration

The textDocument/declaration is consumed with:

the Navigate / LSP Declaration(s) global menu.
or with the Go To/ Declaration(s) editor menu.

This menu action either opens the declaration in a popup or navigates to the declaration if there are several declarations:

textDocument/declaration is also used via Find Usages to show declarations.

Document Highlight

textDocument/documentHighlight is implemented via the highlightUsagesHandlerFactory extension point. As this extension point supports any language, it works out-of-the-box.

Here is an example with the Qute language server, highlighting item variables:

Document Link

textDocument/documentLink is implemented via:

an externalAnnotator extension point, to display a documentLink with an hyperlink renderer.
a gotoDeclarationHandler extension point, to open the file of the documentLink.`

As those extension points support any language, textDocument/documentLink works out-of-the-box.

Here is an example with the Qute language server, displaying an include template with an hyperlink renderer (Ctrl+Click opens the document link):

Hover

textDocument/hover is implemented with the platform.backend.documentation.targetProvider extension point, to support any language, making textDocument/hover work out-of-the-box for all languages.

Here is an example with the Qute language server showing documentation while hovering over an include section:

Syntax Coloration

LSP4IJ supports Syntax Coloration on hover and completion documentation. Here is an example with Rust Analyzer:

Syntax Coloration is supported in:

MarkDown Fenced Code Block.

   ```ts
   const s = "";
   const c = s.charAt(0);
   ```

It will apply the TypeScript TextMate highlighting, inferred from the ts file extension, and will be rendered like:

MarkDown Indented Blockquote (> following with 5 spaces).

>     const s = '';
>     const c = s.charAt(0);

will use the Syntax coloration which triggers the hover / completion.

Syntax coloration discovery

The rules to retrieve the proper syntax coloration are:

if the code block defines the file extension, LSP4IJ tries to apply a matching TextMate grammar or custom syntax coloration by filename, mimetype.
if the code block defines a language Id (e.g. typescript) and the syntax coloration must be retrieved from TextMate, it will use the fileNamePatterns extension point or [./UserDefinedLanguageServer.md#mappings-tab](fileNamePattern of User defined language server) to find the file extension (e.g. ts) associated with the languageId (e.g. typescript)

   ```typescript
   const s = "";
   const c = s.charAt(0);
   ```

if the code block doesn't define the language, or indented blockquotes are used, it will fall back to the syntax coloration from the file in which the hover / completion documentation request was triggered.

If those strategies are insufficient for your needs, please create an issue to request an extension point for mapping the language and the file extension.

CodeLens

textDocument/codeLens is implemented with the codeInsight.codeVisionProvider extension point. As LSP4IJ registers LSPCodeLensProvider for all languages associated with a language server, it works out-of-the-box.

Here is an example with the Qute language server, which shows REST services URL with codeLens:

Inlay Hint

textDocument/inlayHint is implemented with the codeInsight.inlayProvider extension point. LSP4IJ registers LSPInlayHintProvider for all languages associated with a language server with LSPInlayHintProvidersFactory, so it works out-of-the-box.

Here is an example with the Qute language server showing the parameter's Java type as inlay hint:

Document Color

textDocument/documentColor is implemented with the codeInsight.inlayProvider extension point. LSP4IJ registers LSPColorProvider for all languages associated with a language server with LSPInlayHintProvidersFactory, so it works out-of-the-box.

Here is an example with the CSS language server showing the color's declaration with a colored square:

Completion Proposals

textDocument/completion is implemented with LSPCompletionContributor class declared with the completion.contributor extension point. As this extension point supports any language, it works out-of-the-box.

Here is an example with the Qute language server showing method completion:

Completion item resolve

The completionItem/resolve request is implemented to resolve:

the documentation property of a completionItem.

Here a sample with TypeScript Language Server completion item which resolves and shows documentation when the completion item is selected:

the detail property of a completionItem.

Here a sample with TypeScript Language Server completion item which resolves and shows detail when the completion item is selected:

the additionalTextEdits property of a completionItem.

Signature Help

textDocument/signatureHelp is implemented with the codeInsight.parameterInfo extension point. By default, LSP4IJ registers the codeInsight.parameterInfo with LSPParameterInfoHandler class for TEXT and textmate languages:

<!-- LSP textDocument/signatureHelp -->
<codeInsight.parameterInfo
        id="LSPParameterInfoHandlerForTEXT"
        language="TEXT"
        implementationClass="com.redhat.devtools.lsp4ij.features.signatureHelp.LSPParameterInfoHandler"/>

<codeInsight.parameterInfo
        id="LSPParameterInfoHandlerForTextMate"
        language="textmate"
        implementationClass="com.redhat.devtools.lsp4ij.features.signatureHelp.LSPParameterInfoHandler"/>

If you use another language, you will have to declare codeInsight.parameterInfo with your language. If codeInsight.parameterInfo for the language is already defined by another plugin or the IDE, you can use order="first" to gain priority:

<codeInsight.parameterInfo
        id="YourID"
        language="YourLanguage"
        order="first"
        implementationClass="com.redhat.devtools.lsp4ij.features.signatureHelp.LSPParameterInfoHandler"/>

Here is an example with the TypeScript Language Server showing signature help:

Folding range

textDocument/foldingRange is implemented with the lang.foldingBuilder extension point. By default, LSP4IJ registers the lang.foldingBuilder with LSPFoldingRangeBuilder class for TEXT and textmate languages:

<!-- LSP textDocument/folding -->
<lang.foldingBuilder id="LSPFoldingBuilderForText"
                     language="TEXT"
                     implementationClass="com.redhat.devtools.lsp4ij.features.foldingRange.LSPFoldingRangeBuilder"
                     order="first"/>

<lang.foldingBuilder id="LSPFoldingBuilderForTextMate"
                     language="textmate"
                     implementationClass="com.redhat.devtools.lsp4ij.features.foldingRange.LSPFoldingRangeBuilder"
                     order="first"/>

If you use another language, you will have to declare lang.foldingBuilder with your language.

Here is an example with the TypeScript Language Server showing folding:

Additionally LSP4IJ registers the an implementation of the codeBlockProvider extension point with LSPCodeBlockProvider for TEXT and textmate languages to provide block brace matching and easy navigation to the beginning/end of the containing block.

As with lang.foldingBuilder, if you use another language, you will have to declare codeBlockProvider with your language.

Below is an example with the TypeScript Language Server showing code block functionality. The IDE's Presentation Assistant shows the default keyboard shortcuts for each supported operating system to trigger these actions.

Selection range

textDocument/selectionRange is implemented with the extendWordSelectionHandler extension point and used via the IDE's Extend Selection (Ctrl+W on Windows/Linux; Opt+Up on Mac) and Shrink Selection (Ctrl+Shift+W on Windows/Linux; Opt+Down on Mac) actions.

Here is an example with the TypeScript Language Server showing Extend/Shrink Selection using textDocument/selectionRange:

Publish Diagnostics

textDocument/publishDiagnostics is implemented with an externalAnnotator extension point. As this extension point supports any language, it works out-of-the-box.

Here is an example with the Qute language server reporting errors:

Code Action

Here is an example featuring the Clojure LSP, which offers code actions:

Quickfix code action (at the top): This type of code action is facilitated by registering a quick fix within the IntelliJ annotation.
Other code actions such as refactoring (at the bottom): These kinds of code actions are handled using Intentions.

For the last type of code action, you can enable/disable them using the Intentions / Language Server preference setting.

Rename

textDocument/rename is implemented with LSPRenameHandler class declared with the renameHandler extension point.

Here is an example with the TypeScript Language Server showing rename of function name:

Formatting

textDocument/formatting / textDocument/rangeFormatting are implemented with LSPFormattingOnlyService / LSPFormattingAndRangeBothService with the formattingService extension point.

Show Message

window/showMessage supports Markdown messages and clickable links.

Here is an example with Rust Analyzer reporting an error:

{
  "type": 1,
  "message": "Failed to discover workspace.\nConsider adding the `Cargo.toml` of the workspace to the [`linkedProjects`](https://rust-analyzer.github.io/manual.html#rust-analyzer.linkedProjects) setting.\n\nFailed to load workspaces."
}

is rendered as a Balloon notification:

You can change the notification behavior of LSP/window/showMessage by using the standard UI Notifications preferences :

Show Message Request

window/showMessageRequest is supported.

Here is an example with Scala Language Server (MetaLS) reporting a message request:

{
  "actions": [
    {
      "title": "Create .scalafmt.conf"
    },
    {
      "title": "Run anyway"
    },
    {
      "title": "Not now"
    }
  ],
  "type": 1,
  "message": "No .scalafmt.conf file detected. How would you like to proceed:"
}

is rendered as a Sticky balloon notification:

You can change the notification behavior of LSP/window/showMessageRequest by using the standard UI Notifications preferences :

Semantic Tokens

Before you start reading this section, please read the User Guide to configure support for semantic tokens.

The semantic tokens support:

uses only textDocument/semanticTokens/full LSP request.
uses the IntelliJ Semantic Highlighting support by implementing HighlightVisitor with the LSPSemanticTokensHighlightVisitor class.
Use SemanticTokensColorsProvider API to get TextAttributesKey from tokenType, tokenModifiers.
By default, LSP4IJ, uses the DefaultSemanticTokensColorsProvider but you can use your own provider with the semanticTokensColorsProvider extension point.

DefaultSemanticTokensColorsProvider

The following table lists the currently predefined mappings:

the Semantic token types column shows the standard LSP Semantic token types.
the Semantic modifiers types column shows the standard LSP Semantic modifier types.
the SemanticTokensHighlightingColors column defines the TextAttributesKey constants declared in the LSP4IJ SemanticTokensHighlightingColors class.
the DefaultLanguageHighlighterColors column defines the standard TextAttributesKey used by IntelliJ that SemanticTokensHighlightingColors inherits.

Semantic token types	Semantic modifier types	SemanticTokensHighlightingColors	(inherited from) DefaultLanguageHighlighterColors
namespace	definition	NAMESPACE_DECLARATION	CLASS_NAME
namespace	declaration	NAMESPACE_DECLARATION	CLASS_NAME
namespace		NAMESPACE	CLASS_REFERENCE
class	definition	CLASS_DECLARATION	CLASS_NAME
class	declaration	CLASS_DECLARATION	CLASS_NAME
class		CLASS	CLASS_REFERENCE
enum		ENUM	CLASS_NAME
interface		INTERFACE	INTERFACE_NAME
struct		STRUCT	CLASS_NAME
typeParameter		TYPE_PARAMETER	PARAMETER
type		TYPE	CLASS_NAME
parameter		PARAMETER	PARAMETER
variable	static + readonly	STATIC_READONLY_VARIABLE	CONSTANT
variable	static	STATIC_VARIABLE	STATIC_FIELD
variable	readonly	READONLY_VARIABLE	LOCAL_VARIABLE
variable		VARIABLE	REASSIGNED_LOCAL_VARIABLE
property	static + readonly	STATIC_READONLY_PROPERTY	CONSTANT
property	static	STATIC_PROPERTY	STATIC_FIELD
property	readonly	READONLY_PROPERTY	INSTANCE_FIELD
property		PROPERTY	INSTANCE_FIELD
enumMember		ENUM_MEMBER	STATIC_FIELD
decorator		DECORATOR	METADATA
event		EVENT	PREDEFINED_SYMBOL
function	defaultLibrary	DEFAULT_LIBRARY_FUNCTION	STATIC_METHOD
function	definition	FUNCTION_DECLARATION	FUNCTION_DECLARATION
function	declaration	FUNCTION_DECLARATION	FUNCTION_DECLARATION
function		FUNCTION	FUNCTION_CALL
method	definition	METHOD_DECLARATION	FUNCTION_DECLARATION
method	declaration	METHOD_DECLARATION	FUNCTION_DECLARATION
method	static	STATIC_METHOD	STATIC_METHOD
method		METHOD	FUNCTION_CALL
macro		MACRO	KEYWORD
label		LABEL	LABEL
comment		COMMENT	LINE_COMMENT
string		STRING	STRING
keyword		KEYWORD	KEYWORD
number		NUMBER	NUMBER
regexp		REGEXP	VALID_STRING_ESCAPE
modifier		MODIFIER	KEYWORD
operator		OPERATOR	OPERATION_SIGN

If you need other mapping:

if you think it is a generic mapping, please create a contribution to define a new SemanticTokensHighlightingColors constants
if the mapping is specific to your language, use the semanticTokensColorsProvider extension point to define your own provider and mapping.

Document Symbol

textDocument/documentSymbol is implemented with the lang.psiStructureViewFactory extension point. By default, LSP4IJ registers the lang.psiStructureViewFactory with LSPDocumentSymbolStructureViewFactory class for TEXT and textmate languages:

<!-- LSP textDocument/documentSymbol -->
<lang.psiStructureViewFactory
        id="LSPDocumentSymbolStructureViewFactoryForText"
        language="TEXT"
        implementationClass="com.redhat.devtools.lsp4ij.features.documentSymbol.LSPDocumentSymbolStructureViewFactory"/>
<lang.psiStructureViewFactory
        id="LSPDocumentSymbolStructureViewFactoryForTextMate"
        language="textmate"
        implementationClass="com.redhat.devtools.lsp4ij.features.documentSymbol.LSPDocumentSymbolStructureViewFactory"/>

If you use another language, you will have to declare lang.psiStructureViewFactory with your language. If lang.psiStructureViewFactory for the language is already defined by another plugin or the IDE, you can use order="first" to gain priority:

<lang.psiStructureViewFactory
        id="YourID"
        language="YourLanguage"
        order="first"
        implementationClass="com.redhat.devtools.lsp4ij.features.documentSymbol.LSPDocumentSymbolStructureViewFactory"/>

Here is an example with TypeScript Language Server which opens the standard File Structure with Ctrl+F12 / Cmd+F12 (also available with the Navigate / File Structure menu) to display TypeScript functions as symbols and navigate them easily:

You can also open the Structure view using the View / Tool Windows / Structure menu:

Call Hierarchy

textDocument/prepareCallHierarchy is implemented with the callHierarchyProvider extension point. By default, LSP4IJ registers the callHierarchyProvider with LSPCallHierarchyProvider class for TEXT and textmate languages:

<!-- LSP textDocument/callHierarchy request support -->
<callHierarchyProvider
        language="TEXT"
        implementationClass="com.redhat.devtools.lsp4ij.features.callHierarchy.LSPCallHierarchyProvider" />
<callHierarchyProvider
        language="textmate"
        implementationClass="com.redhat.devtools.lsp4ij.features.callHierarchy.LSPCallHierarchyProvider" />

If you use another language, you will have to declare callHierarchyProvider with your language:

<callHierarchyProvider
        language="YourLanguage"
        implementationClass="com.redhat.devtools.lsp4ij.features.callHierarchy.LSPCallHierarchyProvider" />

After setting the cursor position in a file, you can view the Call Hierarchy using the Navigate / Call Hierarchy menu (or Ctrl+Alt+H).
Below is an example of a call hierarchy using the Go Language Server:

Type Hierarchy

textDocument/prepareTypeHierarchy is implemented with the typeHierarchyProvider extension point. By default, LSP4IJ registers the typeHierarchyProvider with LSPTypeHierarchyProvider class for TEXT and textmate languages:

<!-- LSP textDocument/typeHierarchy request support -->
<typeHierarchyProvider
        language="TEXT"
        implementationClass="com.redhat.devtools.lsp4ij.features.typeHierarchy.LSPTypeHierarchyProvider" />
<typeHierarchyProvider
        language="textmate"
        implementationClass="com.redhat.devtools.lsp4ij.features.typeHierarchy.LSPTypeHierarchyProvider" />

If you use another language, you will have to declare typeHierarchyProvider with your language:

<typeHierarchyProvider
        language="YourLanguage"
        implementationClass="com.redhat.devtools.lsp4ij.features.typeHierarchy.LSPTypeHierarchyProvider" />

After setting the cursor position in a file, you can view the Type Hierarchy using the Navigate / Type Hierarchy menu (or Ctrl+H).

Workspace Symbol

workspace/symbol is implemented with the gotoSymbolContributor and gotoClassContributor extension points as appropriate for the symbol type(s).

Here is an example with the MicroProfile language server collecting JAX-RS endpoints:

Files

LSPSupport.md

Latest commit

History