Some inconsistencies in Treesitter support

[joeveiga]

Hello @arcticicestudio 👋 !
First of all, great theme! I use it everywhere lol.
I was looking forward to the treesitter support for neovim and enabled it right away when it was released over the weekend. I did notice some weird behavior with typescript. In the gif below you can see the file with treesitter highlight enabled on the left side.

You'll notice that some imports have different colors (L12, for example), and also the decorators (@Component(), @Input(), etc.) are different as well. Same with the class name and interfaces in the class declaration.

Is this an issue with nord-vim? Or maybe some limitation in treesitter? Please advice.
Thanks!

[crispgm]

@joeveiga I think with tree-sitter the color would be more accurate. As you have shown in the screenshot, different kinds of keyword were colored differently. I think this is a feature.

@arcticicestudio for me, the elder version and current version (with tree-sitter) are not designed to be very distinguishable. Is it possible to make some improve on this? I forked Nord-vim and make one by myself:

[vdcow]

@joeveiga It happens because developer of a tree sitter parser decided to highlight all camel case words started from the capital letters as a type

https://github.com/tree-sitter/tree-sitter-typescript/blob/fd08586b72f2ba8776d865b32aca561285c10cfd/queries/highlights.scm#L6

[arcticicestudio]

Hi @joeveiga, @crispgm and @vladimir-didenko 👋, thanks for your contributions 👍
Thanks for your patience, I was on vacation for the last few weeks and I deliberately ignored the "digital life" during this time 😄

This is what I worried about after adding tree-sitter support: Loosing consistency due to “auto-magical“ mapping of syntax elements without dedicated highlighting groups.
With Vim's "traditional" syntax parsing and language plugins it was easier for theme authors to control which elements gets highlighted, i.e. the dedicated jsFuncCall highlighting group is easy to understand and scoped to functions that are called like foo.bar(), but tree-sitter handles this on its own withput providing a dedicated group for such calls. Taking functions calls as an example tree-sitter works better while "traditional" highlighting often failed to detect functions which can be seen quite well on the GIF. On the other side it looks like elements like annotations/decorators are not handed by the TSAnnotation group which is also defined by Nord with nord12 as foreground color, but on the GIF it looks like nord8 is used instead.

@crispgm Which side is the one highlighted by tree-sitter on your screenshot? The right side looks like there are too many elements highlighted with nord9 that should only be used for elements like keywords and operators. The left side looks more like Nord's style, but there are also some elements that are highlighted with the wrong colors like the names of the enum (nord13 instead of nord4).
Do you refer to these defintions of your fork? Looks like all groups are defined, even when they are already linked by default which is why Nord only overrides specific groups and link them to existing groups.

One problem I see here is that tree-sitter might apply the highlighing groups different depending on the language, i.e. the classes from @joeveiga's GIF should not use nord8 but nord7 like the correctly colored DotItem struct from @crispgm's screenshot. I think there is currently no other way than starting to compare the results between tree-sitter and "traditional" highlighting for popular languages and start to play around with the groups to see which are applied for which element. At the moment I don't have a fully running Neovim setup (yet) because I don't use Vim as my IDE, but I guess using nvim-treesitter/playground will help a lot to debug and find solution to these inconsisten highlighting problems.

[crispgm]

@arcticicestudio the left one is tree-sitter from my fork and the right one is official nord-vim. After implementing tree-sitter highlighting, nord9 is basically dominating and it's not as distinguishable as either non-tree-sittered one or my fork (which may regarded as a more distinguishable alternative).

[arcticicestudio]

Thanks for your patience regarding a reply, it's been busy times again. I want to refer to my comment in the arcticicestudio/nord#157 issue that clarifies my decision about creating a dedicated Nord port for Neovim. This will allow to handle highlighting and any other Neovim specific feature significantly easier when being able to use native Lua APIs instead of being bound to VimScript possibilities only.
I'd like to keep this issue open until the new port is available so it can be used as reference when all Neovim specific code will be removed from this port like explained in another comment in the arcticicestudio/nord#157 issue. This will allow use to get rid of the inconsistent highlighting for a technology that is not native to Vim anyway.