Skip to content

Deprecate the 'semantic_tokens' config option in favor of 'augmentsSyntaxTokens' #2350

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

Techatrix
Copy link
Member

@Techatrix Techatrix commented May 31, 2025

The augmentsSyntaxTokens client capability can be used to indicate that the client is going to combine existing syntax tokens with the semantic tokens of the server. This can not only reduce the amount of data that is transferred over the protocol but can also lead to better highlighting as syntax tokens often more accurately distinguish between different language constructs on the syntax level. An example would be keywords where the LSP protocol has a single standard token type compared to syntax highlighting where different keywords are often differentiated between based on their purpose.

The semantic_tokens config had been added for this purpose. The partial option is used to prevent LSP semantic tokens to override existing syntax highlighting of the editor. The benefit of the client capability is that this decision is automatically made by supported editors instead of relying on user to select the right configuration.

The following editors should be unaffected:

  • VS Code: enables partial by default
  • LSP4IJ (JetBrains): does not enable augmentsSyntaxTokens
  • Helix: does not use semantic tokens
  • Zed: does not use semantic tokens
  • Kate: does not enable augmentsSyntaxTokens
  • Eglot (Emacs): does not use semantic tokens
  • lsp-mode (Emacs): does not enable augmentsSyntaxTokens

The following editors are affected:

Sublime Text

Requires the semantic_highlighting config option to be enabled.

Before:
sublime-text-before
After:
sublime-text-after

The new output more closely matches the result when disabling semantic highlighting:

sublime-text-none

Neovim

Tested with tokyonight.nvim

Before:
neovim-before

After:
neovim-after

The zig.vim plugin maps the var, const, comptime and threadlocal keywords to Function which doesn't seem right. Possible fix: ziglang/zig.vim#110

CoC (neovim)

Tested with tokyonight.nvim

Before:
coc-before

After:
coc-after

Vim defines preferred highlighting groups to share group names between many languages. The conventions that have been established by many syntax highlighting configurations are incompatible with LSP semantic highlighting and will result in poor highlighting when mixed together. Because of this, augmentsSyntaxTokens should be disabled in (Neo)vim when not using tree-sitter based syntax highlighting.

Techatrix added 2 commits May 31, 2025 09:36
The `augmentsSyntaxTokens` client capability can be used to indicate
that the client is going to combine existing syntax tokens with the
semantic tokens of the server. This can not only reduce the amount of
data that is transferred over the protocol but can also lead to better
highlighting as syntax tokens often more accurately distinguish between
different language constructs on the syntax level. An example would be
keywords where the LSP protocol has a single standard token type
compared to syntax highlighting where different keywords are often
differentiated between based on their purpose.

The 'semantic_tokens' config had been added for this purpose. The
'partial' option is used to prevent LSP semantic tokens to override
existing syntax highlighting of the editor. The benefit of the client
capability is that this decision is automatically made by supported
editors instead of relying on user to select the right configuration.
@angelozerr
Copy link

@Techatrix I suggest thzt yiu create an issue on Lsp4ij to take care of this capability and if you could explain me how to implement it. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants