Ctrl+hover underline ignores LocationLink.originSelectionRange for TextMate-backed file types (whole document underlined)

[mellonis]

LSP4IJ version: 0.20.1 (current latest)
IDE: IntelliJ Platform 2024.3 baseline (IntelliJ IDEA CE)
Client plugin setup: a thin LSP client plugin that registers a plain FileType (no com.intellij.lang.Language), TextMate-based highlighting, and maps documents to the server via <fileTypeMapping fileType="..." serverId="..." languageId="..."/>.

What happens

Ctrl/Cmd+hover over an identifier underlines the entire document instead of the identifier. Ctrl/Cmd+click navigation itself lands on the correct target — only the underlined span is wrong.

What the server sends

The client advertises textDocument.definition.linkSupport, and the server answers LocationLink with a precise originSelectionRange (the span the spec designates as "the underlined span for mouse interaction"). Trace from the LSP4IJ console:

[Trace] Sending request 'textDocument/definition - (498)'.
Params: { "textDocument": { "uri": "file:///.../check.pma" },
          "position": { "line": 11, "character": 18 } }

[Trace] Received response 'textDocument/definition - (498)' in 0ms.
Result: [
  {
    "originSelectionRange": { "start": { "line": 11, "character": 16 },
                              "end":   { "line": 11, "character": 20 } },
    "targetUri": "file:///.../check.pma",
    "targetRange":          { "start": { "line": 0, "character": 6 },
                              "end":   { "line": 0, "character": 10 } },
    "targetSelectionRange": { "start": { "line": 0, "character": 6 },
                              "end":   { "line": 0, "character": 10 } }
  }
]

The origin range covers exactly the 4-character identifier under the mouse.

Expected

The Ctrl+hover underline covers originSelectionRange (11:16–11:20 here), not the whole file. For contrast, VS Code's client renders the identical response with a word-precise underline.

Likely mechanism

For a file type backed only by TextMate (no registered Language), the PSI is a single plain-text element, so any element-range fallback degrades to the whole document. Since the LSP response already carries the correct span in originSelectionRange, using it for the underline would fix TextMate/plaintext-backed servers without any client-side lexing.

The server here is pmt lsp from https://github.com/mellonis/machine-toolchains — happy to provide more traces or test builds.

[angelozerr]

@mellonis I totally agree with you, but IJ API doesn't allow to customize this range. If your language server supports semantic tokens, LSP4IJ uses an hack to customize this range (by updating a PsiFile built by LSP4IJ) but otherwise it uses range from (real) PsiFile

[mellonis]

Thanks @angelozerr! The interesting wrinkle: this server does support semantic tokens — both its languages advertise legends (["namespace","function","number"] and ["function","variable","number"]), the IDE renders them, and the position in the trace above (main in call main) is covered by a function token. So the semantic-tokens path you describe doesn't seem to engage in our setup.

Our registration shape, in case that's the gate: the plugin registers its own FileTypes (TextMate-highlighted) and maps them with <fileTypeMapping fileType="..." serverId="..." languageId="..."/> — so the PsiFile at hover time is the platform's plain-text one, not one built by LSP4IJ. Does the range hack require LSP4IJ to own the file (e.g. mapping via LSP4IJ's own language/file-name mapping rather than a plugin-registered file type)? Or does it need a newer LSP4IJ than 0.20.1?

Happy to test a dev build or an alternative registration if that helps narrow it.

[angelozerr]

@mellonis I understand that it is super annoying issue, but IJ platform assumes that you have a PsiFile to manage this range. I have spent ling time to try to hack that without success.