Closed I-Want-ToBelieve closed 1 year ago
What exactly is the request here?
Using LSP's semantic highlighting as a complement to Treesitter highlighting eliminates differences with VSCode highlighting.
When neovim is ready to provide LSP semantic tokens, the only thing the theme plugin needs to do is map LSP highlight groups to colors or highlight groups you like to actually see semantic highlights.
Is that somehow different from https://github.com/dracula/vim/blob/master/colors/dracula.vim#L263-L275 ?
Is this something for which we need to monitor NeoVim releases to know when this feature stabilizes?
(I think the answer to my first question is yes.)
(I think the answer to my first question is yes.)
You are right, I quoted the previous question to illustrate what can be done next
https://github.com/dracula/vim/blob/master/colors/dracula.vim#L263-L275 defines some mappings for LSP diagnostic highlight groups
The LSP semantic highlighting group is about the highlighting group of syntax tokens with different semantics
For example a mutable variable and a read-only constant variable can have different LSP highlight groups: LspVariable and LspVariableReadOnly. Thanks to this, we can map them with different colors, the final rendering effect of the theme is the same as VSCode
Is this something for which we need to monitor NeoVim releases to know when this feature stabilizes?
This still needs addressed.
The LSP semantic highlighting group is about the highlighting group of syntax tokens with different semantics
For example a mutable variable and a read-only constant variable can have different LSP highlight groups: LspVariable and LspVariableReadOnly. Thanks to this, we can map them with different colors, the final rendering effect of the theme is the same as VSCode
Contributions welcome :)
Is this something for which we need to monitor NeoVim releases to know when this feature stabilizes?
https://github.com/neovim/neovim/pull/15723 Now there is a neovim plugin that implements LSP semantic highlighting, which can be used but may not be merged into NeoVim for a while
I tried this plugin, and the effect is very good. It can be said that it is very close to the rendering effect of vscode, except for a few small flaws caused by the completely different syntax highlighting mechanism of treesitter and textmate
By customizing highlights.scm The final rendering effect is exactly the same as VSCode!
Highlight group mapping is easy:
use('dracula/vim', {
disable: is_vscode,
cond: can_load,
as: 'dracula',
config () {
vim.cmd('colorscheme dracula')
vim.cmd('hi! link LspParameter DraculaOrangeItalic')
vim.cmd('hi! link LspVariableReadOnly DraculaPurple')
vim.cmd('hi! link LspFunction DraculaGreen')
vim.cmd('hi! link LspMember DraculaGreen')
// vim.cmd('hi! link LspNamespace DraculaCyan')
// vim.cmd('hi! link LspNamespaceDeclaration DraculaCyan')
vim.cmd('hi! link LspProperty Identifier')
vim.cmd('hi! link LspEnumMember Identifier')
// vim.cmd('hi! link LspClass DraculaCyan')
vim.cmd('hi! link LspOperator DraculaPink')
vim.cmd('hi! link @constructor.imported Identifier')
vim.cmd('hi! link @namespace.imported Identifier')
vim.cmd('hi! link @namespace.exported Identifier')
vim.cmd('hi! link @variable.imported.specifier Identifier')
vim.cmd('hi! link @operator.module DraculaPurple')
// vim.cmd('hi! link @constructor.jsx DraculaCyanItalic')
vim.cmd('hi! link @field Identifier')
},
})
But haven't tested other languages, there might be something to break
I don't know what you mean by "customizing highlights.scm."
My major concern is that this appears to be an experimental plugin and not NeoVim coreβI would be more comfortable waiting until the features land in NeoVim core.
What do you think @dsifford? I don't use NeoVim, so I don't know if my understanding of the situation is correct or not.
I think it's fine to accept PRs for this so long as it's wrapped in a has()
condition (like other plugins we support)..
But for very specific customizations, I think it would be safer to customize down to the language level and not broadly...
So, for example.. Instead of @constructor.imported
, maybe do @constructor.imported.javascript
customizing highlights.scm refers to https://github.com/nvim-treesitter/nvim-treesitter#adding-queries
Given that this experimental plugin seems to be different from the LSP semantic highlighting specification, I can submit a PR about the LSP semantic highlighting group mapping after the plugin's author has dealt with it, and about the custom highlights.scm section, There is no definite specification, just record it here for the time being.
Since semantic tokens support was merged (https://github.com/neovim/neovim/pull/21100) dracula themes highlights break when the client attaches.
A 5 sec example using nvim nighlty, dracula and sumneko_lua as lsp: After the client is loaded treesitter highlighting stops.
For now the way I found to go about is to nil
the semanticTokensProvider
when dracula is used or call vim.lsp.semantic_tokens.stop()
for language server or to manually extend the highlight groups like @I-Want-ToBelieve describes above.
As it becomes harder to write good code without a dracula theme π§π»ββοΈ, do you have the chance to extend the themes highlighting to that @dsifford, @benknoble? π
Edit: just found we are already doing quite well, when just disabling semantic.keyword
and semantic.variable
--- lsp/settings/sumneko_lua.lua
return {
settings = {
Lua = {
-- ...
semantic = {
keyword = false,
variable = false,
},
-- ...
},
},
}
As I have said before, contributions are welcome in the form of PRs. This isn't something I use or even would be in a position to test (except that it doesn't break plain old Dracula on Vim).
Last I heard Derek was pretty busy, though he might be in a better position with respect to this feature now.
https://github.com/dracula/vim/issues/271
Machine Info
vim
/gvim
/neovim
): neovimTERM
environment variable: xterm-kittyAdditional Info
https://github.com/theHamsta/nvim-semantic-tokens