add tree-sitter init for publish

[jrmoulton]

I published a new version of this rust binding for the tree-sitter-slint crate. (I've also added @hunger as an owner). If you to include the tree-sitter generated bindings that are on by default with the tree-sitter init command this is the result.

These things can be regenerated for publishing later so including this isn't strictly necessary but I think this would be good to include.

[CLAassistant]

All committers have signed the CLA.

[hunger]

The monorepo has the bare-bones of the tree-sitter support, so do we need these files here?

Neovim and helix both point to https://github.com/slint-ui/tree-sitter-slint, which is just our tree-sitter support without everything else: The neovim/helix devs hated having to pull down everything slint:-) Some more esoteric editors even rely on the tree-sitter code being in the top level of the repo.

In that repo we have all those files. I wonder whether we need to update those? Should that maybe become part of the github workflow to update that repo from the monorepo?

[hunger]

Thanks for making me co-owner of the crate by the way.

Do you think we can maybe automate publishing that crate based in the tree-sitter-slint repo so that the crate stays up to date with the editors?

[jrmoulton]

ah whoops. I missed that there was a new repo. Yeah these aren't necessary here then.

Do you think we can maybe automate publishing that crate based in the tree-sitter-slint repo so that the crate stays up to date with the editors?

yeah should be possible although I'm honestly not sure when it needs updated and when it doesn't.

[hunger]

The grammar stayed in the monorepo and we sync over, so we can do nightly tests to see whether we broke the grammar. We do that manually.

Syncing to the tree-sitter-slint repo we generate all the files with the latest (stable) tree-sitter and commit that. That's a no-op when nothing changed and creates a commit otherwise. That happens in an out of the way branch as neovim pulls from master and just ships that... so we only update master on releases:-)

So the "boring" update sequence just follows master and sees one push per release (if anything changed in the grammar in the release timeframe).