illuminate inner groups for js treesitter template literals

[jssteinberg]

Great plugin!

With default config. For javascript filetype (with treesitter) with styled-jsx results in all the string of template literal to be 'illuminated'.

<style jsx>{`
    p {
        color: red;
    }
`}</style>

To Reproduce have Neovim with treesitter and vim-illuminate.

Make new buffer of filetype javascript, which uses treesitter syntax, with some React component conatining styled-jsx. E.g.:

export default () => (
    const color = `red`;

    <div>
        <p><strong>Red text</strong>, <em>blue text</em></p>
        <style jsx>{`
            p * {
                --color: ${color};
                color: var(--color);
            }

            p em {
                --color: blue;
            }
        `}</style>
    </div>
)

Put cursor in the CSS ruleset. Without plugin configuration the entire template literal content is 'illuminated'.

Expected behavior would be not to illuminate the entire content of the template literal, but illuminate the individual content as CSS groups (since they get syntax highlighting through treesitter).

To ignore this either under_cursor = false or providers_regex_syntax_denylist = { "javasriptstring" } works. But would it be possible to allow illumination of the CSS content within, or any other smart solutions?

---

Note Omitting a minimal init.vim/init.lua/.vimrc will likely result in the issue being closed without explanation.

Sorry for not providing an init.lua. I can cook up one if I'm wrong to assume that you have a Neovim with treesitter syntax for Javascript and vim-illuminate, and that would just reproduce the above.

[RRethy]

https://user-images.githubusercontent.com/21000943/188182263-36a00119-5bad-48dc-9581-e14657670876.mov

Doesn't happen on my machine, closing due to a lack of minimal init file.

I can cook up one if I'm wrong to assume that you have a Neovim with treesitter syntax for Javascript and vim-illuminate, and that would just reproduce the above.

The purpose of the init file is to narrow down the cause, not only to reproduce. For example, I have treesitter javascript parser, but it does happen on my machine for any number of reasons (do you have a css treesitter parser being used there, are you using lsp, is there another plugin messing up the locals query). Another thing that's suspect is that you said providers_regex_syntax_denylist = { "javasriptstring" } works, but it has no effect on anything treesitter related.

[jssteinberg]

Ok, thanks for taking the time, and looks like you're right about treesitter being off. Seems to work at my home machine. Sorry about that.

Would a minimal init file really help in cases like this, since it wouldn't tell if a certain treesitter parser is installed...

[RRethy]

since it wouldn't tell if a certain treesitter parser is installed...

Then it wouldn't be a minimal init file, you are able to specify parsers in the tree-sitter setup. Without a minimal init file, there's not much a plugin dev can do since we don't have access to your machine. It also helps eliminate a lot of other things that might be going on, I've seen enough config issues people file across my plugins to know that people usually have no idea what's in their config and how things interact.

[jssteinberg]

Yes it sure can become a lot. So perhaps you can mention to test with updated treesitter parsers, or something, in the issue template. Hope you hadn’t already, and I missed it 🤣