Codecov Report

Merging #3355 (1e2c64c) into master (03a532b) will increase coverage by 0.37%.
The diff coverage is 84.80%.

@@            Coverage Diff             @@
##           master    #3355      +/-   ##
==========================================
+ Coverage   74.63%   75.00%   +0.37%     
==========================================
  Files         195      195              
  Lines       19782    19821      +39     
  Branches     4427     4439      +12     
==========================================
+ Hits        14764    14867     +103     
+ Misses       3252     3185      -67     
- Partials     1766     1769       +3     

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 03a532b...1e2c64c. Read the comment docs.

Will this require to explicitly enable the languages for semantic tokens to work? My original suggestion was to have semantic tokens by default supported, but that when the user wants to, if it wants so, it could configure specific languages, or also, have it blacklisted for just a few.

EDIT:

Noticed it's possible to configure languages with glob ("*").

Will this require to explicitly enable the languages for semantic tokens to work

I prefer to disable semanticTokens by default, because only clangd/rust-analzyer/gopls supports this by now, users can enable it by themself. Another reason is semanticTokens is not stable enough by now.

@fannheyward okay, I commented that because it could be annoying to have to list the languages, but I saw after that there's glob support.

At that, it should be documented in the added docs that glob pattern can be used to have it enabled for any server that supports it.

be documented in the added docs that glob pattern

Done.

Seems worth noticing that removing the simple default groups provided by g:coc_default_semantic_highlight_groups means to remove vim support for this kind of thing.

means to remove vim support for this kind of thing

No, if the color scheme has TS* hi group defined for vim, for example https://github.com/sainnhe/sonokai/blob/61b796d94e7b0110f1bdf321cc1d19a841697a42/colors/sonokai.vim#L331, semanticTokens highlight supports vim too.

@fannheyward wow, seriously, that's really nice!

Glob pattern isn't working anymore, dunno what happened (not sure whether it ever worked actually). I'm having to use vim.fn['coc#config']('coc.preferences', { semanticTokensFiletypes = {'rust'} }) for it to work with rust-analyzer, {'*'} doesn't work.

Could this be rebased? I (and maybe others) really like it and it doesn't seem there's a timeline for "the great comeback" (I'm afraid my fight had anything to do with that...).

@oblitum I've rebased master to feat/use-ts-hi-group branch.

Nice, thx.

Hi, I'm currently using the CocSem_* highlight groups and I think they are great and a good complement of the TS* groups. Typically, C++ is quite hard to parse and understand for TreeSitter and clangd can provide more information. What I'm saying is that the highlight groups from Tree sitter and the one provided from lsp are not a perfect 1 to 1 mapping and we can have a better experience by combining them instead of trying to map them as it would result in a loss of information.

cc @oblitum tokenModifiers has been handled, something like TSDeprecated will be highlighted.

The problem is, hi group like TSStatic/TSDeprecated/TSReadonly are not defined by nvim-treesitter, we should provide these hi group, or user needed to define by themself.

cc @oblitum tokenModifiers has been handled, something like TSDeprecated will be highlighted.

Nice. I tried it with Go (I had to :hi link TSDeprecated CocDeprecatedHighlight manually) but got the highlighting only at definition, never at call site:

All the function calls inside main are for deprecated functions.

The problem is, hi group like TSStatic/TSDeprecated/TSReadonly are not defined by nvim-treesitter, we should provide these hi group, or user needed to define by themself.

Is it good idea to fallback highlighting (to CocDeprecatedHighlight) as commented in #3188 (comment)?

@jackhub No need to hack the code any more, composed highlight group would work, checkout :h CocSem

@jackhub No need to hack the code any more, composed highlight group would work, checkout :h CocSem

Thanks for your great works.

why semanticTokens.filetypes is empty by default? It should be ['*'] that aligns with the old coc.preferences.semanticTokensHighlights.

Because we don't want to surprise users with changed highlights.

Does the user have to explicitly call CocAction('semanticHighlight') to get the highlights, or does coc.nvim automatically make this call if semanticTokens.filetypes is enabled for the current &filetype in vim.
In vim I see semantic highlighting working after calling CocAction('semanticHighlight'), but not automatically, so wanted to confirm if this is expected behavior. Thanks.

does coc.nvim automatically make this call if semanticTokens.filetypes is enabled for the current &filetype in vim.

It should be automatic.

Thanks for confirming, I'll look into my environment to see what's going on.