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:

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/diagnostic (see implementation details)
✅ workspace/diagnostic/refresh
✅ 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 (see implementation details).
✅ 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.
❌ workspace/diagnostic.

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.

External References

LSP4IJ supports integration of externally-added references to language server-derived symbols when appropriate. External references are those that are added client-side by either the same plugin or by other installed plugins, e.g., in a polyglot environment where symbols in one language can be referenced in other languages.

When enabled, this ensures that external references are included in Find Usages results and during symbol rename operations. This feature is disabled by default but can be enabled for a custom language server implementation by overriding LSPReferencesFeature#processExternalReferences(PsiFile) to return true, or for a user-defined language server definition, by setting references.processExternalReferences to true in client configuration, e.g.:

{
  "references": {
    "processExternalReferences": true
  }
}

This feature should only be enabled if you are explicitly aware of plugins that might be contributing client-side external references to a language server's symbols. Note that enabling this feature will result in a textual search, albeit indexed, of the search scope for the symbol name for which references have been requested. This can result in longer overall references search times in larger projects and/or where the language server is supplementary to first-class IDE language support.

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:

Automatic code folding

LSP4IJ's folding range support also includes the ability to designate certain folding ranges as collapsed by default based on a combination of the IDE's Code Folding settings:

and how the folding ranges are categorized by the language server via the kind attribute. By default, the following folding ranges are folded by default:

Those with kind=imports when Imports are configured to be folded by default in the IDE.
Those with kind=comment found on the first line of a file when File header is configured to be folded by default in the IDE.

Here is an example of collapse by default behavior with the Java Language Server showing automatic folding of both the file header comment and imports when the file is opened:

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:

Code block provider

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. For maximum flexibility in the absence of a true AST in the LSP client, code blocks are derived from textDocument/selectionRange first and, failing that, from textDocument/foldingRange.

As with other language-specific EP implementations, 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.

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:

Pull Diagnostics

textDocument/diagnostic is consumed after a textDocument/didOpen and textDocument/didChange with debounce and refresh the LSP diagnostics externalAnnotator.

It doesn't support the related documents.

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.

On-Type Formatting

Server-side on-type formatting

textDocument/onTypeFormatting is implemented with LSPServerSideOnTypeFormattingTypedHandler (typedHandlerextension point) and LSPServerSideOnTypeFormattingEnterHandler (enterHandlerDelegate extension point).

Here is an example with the Java Language Server showing automatic formatting of a code block when the close brace for a surrounding conditional statement is typed:

If desired — for example, for those who want to control when formatting is performed — server-side/LSP-based on-type formatting can be disabled via client configuration as follows:

{
  "format": {
    "onTypeFormatting": {
      "serverSide": {
        "enabled": false
      }
    }
  }
}

Client-side on-type formatting

Not all language servers support server-side on-type formatting, and those that do may be limited in the characters that trigger the feature. To provide an improved editor experience for users of such language servers, LSP4IJ also includes support for client-side on-type formatting. Client-side on-type formatting can be enabled via client configuration with the following settings:

format.onTypeFormatting.clientSide.formatOnCloseBrace - When set to true, formatting is automatically applied when a close brace character is typed. Defaults to false.
format.onTypeFormatting.clientSide.formatOnCloseBraceCharacters - Specifies the exact characters that should treated as a close brace character for purposes of client-side on-type formatting. Defaults to the close brace characters for the language, typically }, ], and ).
format.onTypeFormatting.clientSide.formatOnCloseBraceScope - Specifies the scope that should be formatted when a close brace is typed. Valid values are CODE_BLOCK and FILE. Defaults to CODE_BLOCK.
format.onTypeFormatting.clientSide.formatOnStatementTerminator - When set to true, formatting is automatically applied when a statement terminator character is typed. Defaults to false.
format.onTypeFormatting.clientSide.formatOnStatementTerminatorCharacters - Specifies the exact characters that should treated as a statement terminator character for purposes of client-side on-type formatting. Defaults to empty and must be specified if formatOnStatementTerminator is enabled.
format.onTypeFormatting.clientSide.formatOnStatementTerminatorScope - Specifies the scope that should be formatted when a statement terminator is typed. Valid values are STATEMENT, CODE_BLOCK and FILE. Defaults to STATEMENT. The other values are most useful for language servers that do not support range formatting or yield incorrect results for range formatting.
format.onTypeFormatting.clientSide.formatOnCompletionTrigger - When set to true, formatting is automatically applied when a completion trigger character is typed. Defaults to false.
format.onTypeFormatting.clientSide.formatOnCompletionTriggerCharacters - Specifies the exact characters that should treated as a completion trigger character for purposes of client-side on-type formatting. Defaults to the completion trigger characters specified by the language server.
Note that there is no configurable scope for completion trigger-based formatting. Exactly the type completion trigger character is formatted. As above, support for this may vary by language server.

Note that FILE scope is most useful for language servers that do not support range formatting properly or at all, but of course it results in reformatting of the entire file when a corresponding trigger character is typed. Usage of FILE scope is therefore left to the discretion of the end user.

For example, the TypeScript Language Server does not support server-side on-type formatting at all, but client-side on-type formatting can provide solid incremental formatting of JavaScript and TypeScript source files. The TypeScript language server configuration template therefore includes the following default client-side on-type formatting configuration:

{
  "format": {
    "onTypeFormatting": {
      "clientSide": {
        "formatOnCloseBrace": true,
        "formatOnStatementTerminator": true,
        "formatOnStatementTerminatorCharacters": ";",
        "formatOnCompletionTrigger": true
      }
    }
  }
}

Here is an example of client-side on-type formatting with that configuration showing automatic indentation of a statement continuation when the completion trigger character . is typed and automatic formatting of an entire code block when the closing brace character } is typed for a surrounding conditional statement:

Server-side / client-side on-Type formatting relationship

If server-side on-type formatting is supported by the language server and enabled and client-side on-type formatting is enabled for specific trigger characters, only client-side on-type formatting will be applied when those specific trigger characters are typed.

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

Structure View

The IDE's lang.psiStructureViewFactory extension point is implemented using textDocument/documentSymbol. 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:

Breadcrumbs and Sticky Lines

The IDE's breadcrumbsInfoProvider extension point is also implemented using textDocument/documentSymbol. LSP4IJ registers the extension point for all file types and languages but filters at runtime for those associated with configured language server definitions.

The feature is enabled by default but can be disabled by overriding the respective feature flag either in code by overriding LSPBreadcrumbsFeature#isEnabled() (custom language server definitions) or client configuration (user-defined language server definitions). Note that sticky lines are only supported in JetBrains 2024.1+ IDE versions.

Here is an example of breadcrumbs and sticky lines in TypeScript:

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:

FilesExpand file tree

LSPSupport.md

Latest commit

History