zls icon indicating copy to clipboard operation
zls copied to clipboard

remove support for `textDocument/semanticTokens/full`

Open Techatrix opened this issue 4 months ago • 2 comments

The current implementation of semantic tokens does not scale well with larger file sizes which can negatively impact the editing experience. A possible solution would be to remove support for textDocument/semanticTokens/full so that editors instead use textDocument/semanticTokens/range to request semantic tokens only for the visible part of the editor instead of the entire file.

This use case is being mention in the LSP specification:

if computing semantic tokens for a full document is too expensive servers can only provide a range call. In this case the client might not render a minimap correctly or might even decide to not show any semantic tokens at all.

The following editors can use semantic tokens and will need to be investigated on how they would react to this change:

  • VS Code (already implemented)
  • Sublime Text LSP
  • Neovim
  • Coc (vim)
  • LSP4IJ (JetBrains)
  • Kate
  • lsp-mode (Emacs)

Techatrix avatar Sep 09 '25 20:09 Techatrix

Just for your information LSP4IJ doesnt summprt semantic with range it supports only semantic with full

angelozerr avatar Oct 05 '25 09:10 angelozerr

That's good to know. When a client only supports full semantic tokens then we can continue to provide it so that we don't lose semantic tokens. The more interesting case is with clients that support both full and range semantic tokens where they may behave differently if they are only provided range semantic tokens. I haven't yet looked through all the client capabilities to check which editors this would apply to.

Techatrix avatar Oct 07 '25 23:10 Techatrix