feat: add git_config query

[Danielkonge]

This adds highlighting to git_config files. From what I can tell the only query needed is the included section_header query, since git_config files have a pretty simple syntax.

[HiPhish]

Can section headers be nested? I don't really see the point of highlighting delimiters if they are all on the same level regardless. Do you have some specific use-base in mind?

Also, can you please remove the dot from the test file name? If you Neovim to detect the file type reliable prefer a modeline instead, like this: ; vim:ft=gitconfig.

[Danielkonge]

Can section headers be nested? I don't really see the point of highlighting delimiters if they are all on the same level regardless. Do you have some specific use-base in mind?

I don't think headers can be nested. My use case is just that I use rainbow-delimiters for all my delimiter highlighting except unit types (like () in rust, which I like to be gray - my standard parenthesis color).

If you prefer not to include this in rainbow-delimiters, I will just have to do my own custom query for highlighting in gitconfig files.

Also, can you please remove the dot from the test file name? If you Neovim to detect the file type reliable prefer a modeline instead, like this: ; vim:ft=gitconfig.

I renamed the file and added modeline instead.

[HiPhish]

I think this is more suited to your personal config (~/.config/nvim/after/queries/git_config/rainbow-delimiters.scm). It's just one simple pattern, so it's not hard to maintain either. Please file an issue if there are any problems with maintaining your own query in your Neovim configuration.

I am trying to put myself in the shoes of some regular user: he opens a Git config file and then finds that the section headers are highlighted all weirdly for apparently no reason. This would violate the principle of least astonishment. I don't think section headers really qualify as delimiters if there can never be more than one level.

I am open to counter-arguments though.

[Danielkonge]

I think this is more suited to your personal config (~/.config/nvim/after/queries/git_config/rainbow-delimiters.scm). It's just one simple pattern, so it's not hard to maintain either. Please file an issue if there are any problems with maintaining your own query in your Neovim configuration.

I am fine with just maintaining this myself, and if I notice any problems I will file an issue.

I am trying to put myself in the shoes of some regular user: he opens a Git config file and then finds that the section headers are highlighted all weirdly for apparently no reason. This would violate the principle of least astonishment. I don't think section headers really qualify as delimiters if there can never be more than one level.

I am open to counter-arguments though.

As a counter-argument, I would think that a user of this plugin would expect it to be active in all files they open (at least that is basically my expectation). Of course if there is no treesitter parser there is nothing we can do, or if the parser gives us very little to work with like in math in latex, it is also hard to give the "expected" behavior. But overall I think that users would expect highlighting of (), [], {}, <> pairs in almost all files.

[HiPhish]

I agree in principle, but let's take a step back: what is even the point of rainbow delimiters? It provides alternating highlighting of nested delimiters so users can immediately see the levels of hierarchy and which delimiters belong together. The definition of "delimiter" is somewhat flexible, e.g. we could consider the def foo(): in Python to be a delimiter without a closing counterpart, and it might make sense to have a sort of rainbow-blocks query in Python.

However, without any nesting are we gaining anything over just using regular Tree-sitter highlighting? I don't think so because there is no alternating. The end result looks the same, but now we have all the computational and cognitive overhead of rainbow delimiters; we are checking for nesting levels which will never exist. You could have defined the same pattern in highlight.scm with a capture named @GitConfSectionBracket and then define highlighting like :hi link @GitConfSectionBracket RainbowDelimiterRed or some other group.

[Danielkonge]

I agree in principle, but let's take a step back: what is even the point of rainbow delimiters? It provides alternating highlighting of nested delimiters so users can immediately see the levels of hierarchy and which delimiters belong together.

That is probably the intended point of rainbow delimiters, but I would expect that some users (like me) use rainbow-delimiters to highlight delimiters in general. (Though again, I am fine with you sticking to the intended use. rainbow-delimiters is customizable enough that I can do what I want with it by making custom queries.)

The definition of "delimiter" is somewhat flexible, e.g. we could consider the def foo(): in Python to be a delimiter without a closing counterpart, and it might make sense to have a sort of rainbow-blocks query in Python.

I had thought about creating a rainbow-blocks query for Python myself, but it is currently impossible, yes. If iter_matches is ever fixed, we should be able to do it though.

However, without any nesting are we gaining anything over just using regular Tree-sitter highlighting? I don't think so because there is no alternating. The end result looks the same, but now we have all the computational and cognitive overhead of rainbow delimiters; we are checking for nesting levels which will never exist. You could have defined the same pattern in highlight.scm with a capture named @GitConfSectionBracket and then define highlighting like :hi link @GitConfSectionBracket RainbowDelimiterRed or some other group.

There are a few ways of doing what I want, but I generally like to keep extra files/code to a minimum. In this case I prefer to use rainbow-delimiters.scm over highlight.scm, since I am much more used to working with rainbow-delimiters. (Also, when there is no nesting + basically always small file sizes, rainbow-delimiters is really not doing much.)

[HiPhish]

Eh, I'm still not convinced and I think it would be more perceived as more unexpected than expected. If more people come forward who want it I will put it in, but for now let's leave things as they are.

[Danielkonge]

Ok, I will just close this for now then.

As a last comment: I think people are used to the pre-treesitter rainbow parenthesis kind of plugin in other editors, so I still think that it is most common to always expect parenthesis highlighting.