bug: Semantic token highlighting not working in rust format macros

[itsfrank]

Neovim version (nvim -v)

v0.11.1

Terminal / multiplexer

Wezterm

Describe the bug

See the screenshots below:

Rose-pine:

Oxocarbon:

Notice how the variable interpolation in the format string gets syntax highlighting in oxocarbon, but not rose pine

Inspect output when hovering over hello on line 3:

---

Note that I do have tresitter, but disabling it does not seem to help

Rose pine with TS disabled:

Oxocarbon with TS disabled:

Repro

Ensure that rust-analyzer is installed somehow (I used rustup with rustup component add rust-analyzer)

vim.o.packpath = "/tmp/nvim/site"

local plugins = {
  rose_pine = "https://github.com/rose-pine/neovim",
  -- ADD OTHER PLUGINS _NECESSARY_ TO REPRODUCE THE ISSUE
}

for name, url in pairs(plugins) do
  local install_path = "/tmp/nvim/site/pack/test/start/" .. name
  if vim.fn.isdirectory(install_path) == 0 then
    vim.fn.system({ "git", "clone", "--depth=1", url, install_path })
  end
end

require("rose-pine").setup({
  -- ADD ROSÉ PINE CONFIG THAT IS _NECESSARY_ TO REPRODUCE THE ISSUE
})

vim.lsp.config("rust-analyzer", {
  cmd = { "rust-analyzer" },
  root_markers = { "Cargo.toml", ".git" },
  settings = {
    ["rust-analyzer"] = {
      cargo = { allFeatures = true },
      check = { command = "clippy" },
    },
  },
})

vim.api.nvim_create_autocmd("FileType", {
  pattern = "rust",
  callback = function(args)
    vim.lsp.start({
      name = "rust-analyzer",
      cmd = { "rust-analyzer" },
      root_dir = vim.fs.root(args.buf, { "Cargo.toml", ".git" }),
      settings = { ["rust-analyzer"] = { cargo = { allFeatures = true } } },
    })
  end,
})

vim.lsp.enable("rust-analyzer")

vim.cmd("colorscheme rose-pine")

[itsfrank]

Screenshots in the post above are with my full config, here are the screenshots with the minimal config I added to the original post:

Nvim default colorscheme:

Rose pine:

Default seems to have the same color for the braces as the string, but the variable is highlighted differently

Inspect output hovering over "text" with minimal config

Default color scheme:

Rose pine:

[pkazmier]

I believe the problem is that rose pine does not define all of the semantic highlight groups. In the case of your string above, you need these two hl groups defined:

      ["@lsp.type.formatSpecifier"]  = { link = "@markup.list" },
      ['@lsp.type.variable']         = { link = '@variable' },

Someone likely needs to add many more of these to the plug-in. If the maintainers would be amenable, I'd be happy to go copy them from Tokyonight, adjust as necessary, and submit a PR. After adding the two above, you can see the format string looks as you had expected.

In the meantime, you can just add them to your personal configuration:

  require("rose-pine").setup({
    -- stylua: ignore
    highlight_groups = {
      ["@lsp.type.formatSpecifier"]  = { link = "@markup.list" },
      ['@lsp.type.variable']         = { link = '@variable' },
    },
  })

[mvllow]

@pkazmier thank you for finding these highlight groups. I know we intentionally left some semantic groups such as @variable unset in the past (not sure if they still are unset) due to how things are sometimes inherited but these groups should be fine to add.

[pkazmier]

After looking at this more closely this morning, I don't think I'd recommend setting @lsp.type.variable to link to @variable. By doing so, one loses the ability to apply syntax coloring in several cases at a tradeoff of being able to do so with variables within format strings. When it comes to variables, it seems LSP servers don't have the granularity at the variable level that treesitter does. So I now understand why rose-pine and other colorschemes explicitly set @lsp.type.variable to {} and let treesitter handle variable syntax highlighting. With that said, I think there is no harm in adding @lsp.type.formatSpecifier, which would get some syntax highlighting in the OP's example.

Here are some examples to illustrate. In each pair of images, the first is rose-pine today where @lsp.type.variable is set to {} and the second is when it is linked to @variable.

Go Example 1

Go Example 2

Python Example 1

Python Example 2