String containing single curly brackets

[davidbgonz]

Hello, First of all, thank you for creating this. I work in a lot of helm charts in neovim and the no syntax highlighting was driving me insane. I was working on a helm template that contains a string value that consists of a UUID surrounded by curly brackets. The syntax highlighting gets confused, but what's interesting is after a comment, it goes back to normal. Is there something in the highlights.scm file I can add to handle single curly brackets inside strings? Also I am not sure why the data: line in the file is being highlighted in a different color. The setup I followed was the same as what you have (using lspconfig) in the readme except for the file detection since I use a separate plugin for file type detection.

I attached a screenshot of a simplified example of the config I was working on:

[ngalaiko]

Hey, I won't spend any time on this project in the near future.

Would appreciate the help if you want to fix it yourself

[davidbgonz]

Sure thing, I can give it the ole' college try.

[msvechla]

I experience the same thing, I also want to try to look into this, but any pointers would be helpful

[msvechla]

I was able to create the following failing test case:

====================================
mycase
====================================
test: "helloWorld{"
---
(template
    (text))

running it produces:

(template
      (text)
      (text)
      (text))

instead of:

(template
      (text))

I was not able to fix it yet though.

It might have something to do with the following in grammar.json:

    text: $ => choice(
        // forbid '{{', the rest is valid
        /[^{]+/,
        /\{/,
    ),

If you have any ideas, please let me know!

[ngalaiko]

@msvechla that's a great start!

unfortunately the only advice I can give is:

• make sure to go through https://tree-sitter.github.io/tree-sitter/creating-parsers
• don't hesitate if change you make seems "too big". most likely I've written the grammar in a way that sucks and makes it very hard to support this edge-case.

[msvechla]

I did a little bit of testing and I got some of the stuff fixed. The grammar might look a bit worse now, but the parsing looks a lot better now for my cases.

Here is an example of my updates, comparing a default helm deployment.yaml template:

It also shows your issue @davidbgonz, which should be fixed as well. If you want to test it, you can check out my branch:

local parser_config = require'nvim-treesitter.parsers'.get_parser_configs()
parser_config.gotmpl = {
  install_info = {
    url = "https://github.com/msvechla/tree-sitter-go-template",
    branch = "fix_brackets",
    files = {"src/parser.c"},
  },
  filetype = "gotmpl",
  used_by = {"gohtmltmpl", "gotexttmpl", "gotmpl"},
}

And then re-run :TSInstall gotmpl

[davidbgonz]

@msvechla It's a great improvement. All of the sections that were previously not highlighted are now corrected. I notice an oddity with highlighting in cases when quote wrapped strings have a word then a trailing space after that first word. It occurs on both single and double quotes.

Before:

After:

It doesn't have to be in a list, the shortest way to replicate this is foo: "bar ". It's a pretty niche case since I would only ever use quote wrapped multi-word strings in single line lists. I don't see this issue in multiline strings (| or |- look okay), and I also do not see this issue inside any gotmpl sections. For example, if the image line had something like ( .tag | default "foo bar" ), the beginning "foo section would be correctly highlighted.

[msvechla]

Thanks for the input, I added yet another fix, feel free to re-install from my branch.

There will be probably more of those small issues, which can probably only be solved with a full re-write. Even then there might be cases that will be difficult to solve like in-line templates similar to:

hello: "{{ .Value.world }}-test"

At least I currently don't know how to parse both the surrounding quotes including the plain-text string and the go template correctly. In my current approach at least the parsing fails gracefully and the rendering of the remeining file should still be correct.

Thats the best I can provide as a fix right now, but for me this fixes most of the issues I experienced

[davidbgonz]

Thanks for the fix. Yeah, it definitely fixes most of the issues. I see what you say with the graceful failing:

Single line lists with more than 2 items are pretty few and far between for me, and if it bugs me enough I can always just use multiline yaml. I'll take this as a win.

[msvechla]

I've made some further adjustments that cover your example, but there will be more edge cases that are not covered. I will think about a more drastic re-write when I have some spare time.

[davidbgonz]

Looking good now. If you ever think about doing the re-write let me know and I'll be your lab rat.

[ngalaiko]

@msvechla I've added you as a collaborator so that you can push