Do not override treesitter lua highlighting with sumneko lua highlighting

[errantepiphany]

I noticed that when opening a lua file, the highlighting initially looks really nice. (Thanks treesitter!) But then once sumneko_lua is done initializing, the highlighting changes slightly (specifically, parent fields turn back to white). This is because sumneko overrides treesitter's highlighting with its own. So this PR disables the sumneko highlighting so we can keep the pretty treesitter one.

This is the field: https://github.com/sumneko/lua-language-server/wiki/Settings#semanticenable

Signed-off-by: David Ward [email protected]

[seantwie03]

Thanks for your contribution! Better colors = good. 😄

I'm still a bit of a noob when it comes to LSP, with this configuration could there ever be a conflict between treesitter highlighting and LSP error reporting? If treesitter and sumneko parse a file differently and disagree on what a symbol is, could it lead to confusion? For example: "It is highlighted like an 'X', but sumneko is treating it like a 'Y' and throwing weird errors."

[errantepiphany]

@seantwie03 According to the sumneko documentation, the entire semantic group of configuration properties only has to do with highlighting. I guess it could be possible that treesitter's grammar could mistakenly consider a token to be something different than what sumneko thinks it is, however the only repercussion of that would be a mis-coloring. But the LSP behavior would not be affected. But again, this is according to the docs. If the docs are wrong or misleading, then I could be wrong.

[seantwie03]

Thanks for the links to the docs. I agree with you. Any error scenario like this is probably going to be very infrequent.

[tjdevries]

I wonder if it's just because this colorscheme hasn't been updated yet to have the semantic highlights be good colors? I'll have to follow up on that to find that out.

[errantepiphany]

Hi @tjdevries, thanks for looking at this. I will describe exact examples of the behavior I'm seeing with two different color schemes, the moment right after sumneko_lua finishes initializing:

navarasu/onedark.nvim

• semantic enabled: the use keyword changes from blue to red (bad), but the vim.fn field stays blue (good)
• semantic disabled: the use keyword stays blue (good), and the vim.fn field stays blue (good)

Mofiqul/dracula.nvim

• semantic enabled: the use keyword changes from green to orange (bad), and the vim.fn field changes from orange to white (bad)
• semantic disabled: the use keyword stays green (good), and the vim.fn field stays orange (good)

There could be other color issues, but I just wanted to give a couple examples that stood out to me. This might be a problem in sumneko_lua, however doesn't that become moot if we can just stop it from clobbering tree-sitter's colors with this PR?

[tjdevries]

use is not a keyword -- it's a variable (actually, it's a parameter passed to the function). My guess is it's highlighting parameters as different things than regular variables. I think that's personal preference on what you'd want to do.

It'd be helpful to see screenshots, but I'm unlikely to turn it off by default I think. I'll try and do some testing this week though and maybe I'll end up agreeing with you haha

[errantepiphany]

Oops, yeah, you're right: use is a parameter. But vim.fn is a field, and both are getting clobbered. So it's not just a parameter-thing. Thanks again; I appreciate your time on this. I know it's small, but it's annoying to see colors unintentionally change (for the worse) a couple seconds after you open the file.

[tjdevries]

It's no problem -- I learned something new that sumneko has added support for semantic highlights :)

I'll keep this open for a bit while I think about it, but ultimately kickstart should just be the place where you start your config, so feel free to apply this change in your local copy! 😄

[errantepiphany]

@tjdevries I need to apologize for wasting your time. I created some screenshots, highlighting the differences with semantic enabled and disabled (for both colorschemes), and now I'm confused. Regarding the tokens, there's some things that look more "right" with tree-sitter doing the highlighting, and other things that look more "right" with sumneko doing the highlighting [1]. To confuse things more, after looking more closely, it also looks like there are further behavioral differences when using onedark vs. dracula (or vice-versa). I'm going to attach some screenshots. Long story short, there's a lot of irregularities here, and now I don't know where the problems (plural) are coming from.

So yeah... Probably best to close this PR un-merged. The issues are elsewhere, and not really kickstart.nvim's problem to worry about. Sorry again.

[1] use colors should match, so I recant.

onedark semantic enabled

onedark semantic disabled

dracula semantic enabled

dracula semantic disabled

[CharlesChiuGit]

@errantepiphany Maybe u can try :TSHighlightCapturesUnderCursor to see which highlight group is taking charge, a command from ts-playground

[craigmac]

If you've got a very recent Neovim you can also now do: :Inspect and :Inspect! (for pretty-print)

[tjdevries]

Yeah, let's close for now (and fix any upstream issues if they exist). Thanks for doing all this tracking down and no worries at all :) Thanks for the detailed write ups!