Need help to contribute injection

[ignamartinoli]

Hi, I would like to contribute with an injection for Hyperscript.

It is an embedded language that should be put inside the _ tag.

Here is a Treesitter grammar: https://github.com/dz4k/tree-sitter-_hyperscript

I came up with this query to inject it:

((attribute
  (attribute_name) @name
  (quoted_attribute_value
    (attribute_value) @value))
 (#eq? @name "_"))

I would like to open a PR, but I am a bit lost.

After looking at the injection file, I assume that what I should put there is:

((attribute
  (attribute_name) @name
  (quoted_attribute_value
    (attribute_value) @value))
 (#eq? @name "_")
 (#set! injection.language "_hyperscript"))

Am I right? Any feedback is appreciated.

[zyriab]

I think we should add this as a parser to Treesitter directly and not as an extension of HTML.
I did extend the HTML parser in my own config, it's not working yet but the injections work, I think the issue is either related to the installation of the custom parser/grammar or the grammar itself.
If anyone wants to join on the fun: dz4k/tree-sitter-_hyperscript#1 (comment)

[ignamartinoli]

Heyyy @zyriab.
I agree that we should add this directly in Treesitter

[zyriab]

Hey @ignamartinoli I talked with Deniz, the author of the grammar and he told me it's not working to begin with.

I guess we should write one ourselves, I don't have the time to do it right now but might look into it at some point (no promise though!).

I've put an update to my comment on the grammar's repo

[ignamartinoli]

Well, mystery solved.

I don't have the time either to tackle this. Maybe in the next month after a couple of exams.

If you happen to begin to work on this hit me up. I would gladly help

[ignamartinoli]

Hi everyone (@zyriab, @bigskysoftware), I have some good news!

I’ve successfully built a complete Tree-sitter parser, and it correctly highlights all examples from the official website. Here’s a preview:

That said, there’s a downside. The parser is currently quite large (~9 MB), and when I add support for clauses like
the next|previous <expr> [from <expr>] [within <expr>] [with wrapping], it grows to around 18 MB.

I’m considering publishing this in a repository, so the community can try it out. Ideally, someone with more experience in Tree-sitter optimization might be able to help reduce the parser size.

Suggestions are welcome!