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:
Current state of Base protocol support:
- ✅ $/cancelRequest.
- ✅ $/progress (see implementation details)
Current state of Text Document Synchronization support:
- ✅ textDocument/didOpen.
- ✅ textDocument/didChange.
- ✅ textDocument/didClose.
- ✅ textDocument/didSave.
- ❌ textDocument/willSave.
- ❌ textDocument/willSaveWaitUntil.
Notebooks are not supported.
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.
- ❌ textDocument/incomingCalls.
- ❌ textDocument/outgoingCalls.
- ❌ textDocument/prepareTypeHierarchy.
- ❌ typeHierarchy/supertypes.
- ✅ textDocument/foldingRange (see implementation details)
- ❌ textDocument/selectionRange.
- ✅ 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.
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.
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.
$/progress is implemented with Background Tasks
.
Here a sample with Eclipse JDT Language Server:
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.
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 too via Find Usages to show references.
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 too used via Find Usages to show implementations.
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 used too via Find Usages to show Type definitions.
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 used too via Find Usages to show declarations.
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:
textDocument/documentLink is implemented via:
- an
externalAnnotator
extension point, to display adocumentLink
with an hyperlink renderer. - a
gotoDeclarationHandler
extension point, to open the file of thedocumentLink
.`
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):
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:
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 with5 spaces
).
> const s = '';
> const c = s.charAt(0);
will use the Syntax coloration which triggers the hover / completion.
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.
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:
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:
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:
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:
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.
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:
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 Go Language Server showing folding:
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:
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.
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:
textDocument/formatting / textDocument/rangeFormatting are implemented with
LSPFormattingOnlyService /
LSPFormattingAndRangeBothService with the formattingService
extension point.
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 :
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 :
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.
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 theTextAttributesKey
constants declared in the LSP4IJSemanticTokensHighlightingColors
class. - the
DefaultLanguageHighlighterColors
column defines the standardTextAttributesKey
used by IntelliJ thatSemanticTokensHighlightingColors
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.
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 too open the Structure
view with View / Tool Windows / Structure
menu:
workspace/symbol is implemented with the gotoSymbolContributor
extension point.
Here is an example with the MicroProfile language server collecting JAX-RS endpoints: