Bug: Comment tags conflicting with LSP?

[chrisgrieser]

so here is how the comment tags look in a buffer where I do not have an LSP attached (shell script):

and here how it looks in a buffer with a LSP attached (lua):

I could roughly pinpoint the LSP being the cause of this, since the correct highlighting briefly appears, and as soon as semantic highlights from the LSP are added, the comment tags highlighting turns from the first to the second screenshot.

(also, FIX does not seem to work ever for whatever reason?)

[stsewd]

Hi, this is due to semantic tokens having a higher priority than tree-sitter, see :h vim.highlight.priorities to change that globally, or you can change this per-capture :h treesitter-highlight-priority.

(also, FIX does not seem to work ever for whatever reason?)

That keyword isn't highlighted by default https://github.com/nvim-treesitter/nvim-treesitter/blob/master/queries/comment/highlights.scm, you can propose that keyword in nvim-treesitter or extend the query locally (:h treesitter-query).

[chrisgrieser]

Hi, this is due to semantic tokens having a higher priority than tree-sitter, see :h vim.highlight.priorities to change that globally, or you can change this per-capture :h treesitter-highlight-priority.

I am actually a bit irritated by this. With semantic tokens being enabled by default, almost no treesitter user will ever see the nice comment highlighting from this parser. At the very least, instructions on how to be able to see them should be documented. However, since every treesitter parser other than this one works out of the box, I do not think many people will actually ever come across this repo's readme and be able to learn that they have to do extra stuff to enable comments tag highlighting.

In my opinion, there should be some changes made – not sure whether here or at treesitter or at nvim core – since it really is a bummer to have such a nice parser that effectively has no effect unless a user finds this issue and then puts in the time to figure out how to define highlights per capture.

That keyword isn't highlighted by default https://github.com/nvim-treesitter/nvim-treesitter/blob/master/queries/comment/highlights.scm, you can propose that keyword in nvim-treesitter or extend the query locally (:h treesitter-query).

this, too, actually confuses me a bit. The readme of this parser sounds like any kind of uppercase word would work? Does treesitter redefine what gets highlighted? I thought it was the parsers determining what actually gets highlighted. The readme makes it sound like what comments get parsed is determined by this parser, not by the treesitter repo? ("If you think there are other popular conventions this syntax doesn't cover, feel free to open a issue.")

[stsewd]

I am actually a bit irritated by this. With semantic tokens being enabled by default, almost no treesitter user will ever see the nice comment highlighting from this parser. At the very least, instructions on how to be able to see them should be documented. However, since every treesitter parser other than this one works out of the box, I do not think many people will actually ever come across this repo's readme and be able to learn that they have to do extra stuff to enable comments tag highlighting.

I think the main problem here is that the lua LSP has a semantic token for comments, which doesn't sound useful, but this happens for all other LSPs and tokens in general, not just comments; variables, classes, etc, they all are being highlighted twice, and most of them are linked to the same hl group, so you don't notice that they are being highlighted again.

You can disable the hl group for comments from LSP with:

vim.api.nvim_set_hl(0, '@lsp.type.comment', {})

In my opinion, there should be some changes made – not sure whether here or at treesitter or at nvim core – since it really is a bummer to have such a nice parser that effectively has no effect unless a user finds this issue and then puts in the time to figure out how to define highlights per capture.

Yeah, this should probably be discussed in neovim, maybe start by adding a note that using semantic tokens can interfere with treesitter.

The readme of this parser sounds like any kind of uppercase word would work? Does treesitter redefine what gets highlighted? I thought it was the parsers determining what actually gets highlighted.

The queries from nvim-treesitter used to highlight all tags, but it resulted in several false positives, so now the queries are more specific, you can highlight all recognized tags with this query:

[
 "("
 ")"
] @punctuation.bracket

":" @punctuation.delimiter

(tag
  (name) @text.todo
  (user)? @constant)

[stsewd]

Others agree that it's also not useful to have the lua LSP highlight comments

• https://gist.github.com/swarn/fb37d9eefe1bc616c2a7e476c0bc0316?permalink_comment_id=4536237#gistcomment-4536237
• https://github.com/LuaLS/lua-language-server/issues/1809

So I think this can be solved by the lua LSP instead of neovim.

[chrisgrieser]

alright, I have added some common tags via PR (see above)

---

you can highlight all recognized tags with this query (…)

having no experience with treesitter (other than being a user), could you maybe add some instructions to the readme how to add some custom comment tags? (with some info which ones are actually enabled by default)

[stsewd]

having no experience with treesitter (other than being a user), could you maybe add some instructions to the readme how to add some custom comment tags? (with some info which ones are actually enabled by default)

I can put a small paragraph, but this is more like a neovim usage question than something that should be in the parser.