Add GDScript to supported languages

[rinOfTheStars]

Doesn't actually implement any scopes (though it does define a few as being notApplicable), but defines gdscript (.gd) as a supported language, easing further development by not requiring me to run a local build of Cursorless when working on actual scope implementations in the future. This has been done for quite a while but I've not had the time to submit the PR until now due to a generally stressful fall semester and catching COVID during the first week of classes, so I thought I'd get the PR in now before I forget again >.<

[AndreasArvidsson]

You need to run prettier. That is what pre commit is complaining about.

[rinOfTheStars]

Converting this into a draft until I figure out what the solution is to the issue w/ gdscript tests mentioned on the Talon Slack

[rinOfTheStars]

So, I found the solution, but I'm not sure how to actually work around the requirements it imposes:

In order to properly generate tests (and presumably run them as well), the monorepo must be nested inside of a Godot project, or considered a Godot project in of itself, and that project must also be running in a Godot Editor instance (which can, thankfully, be headless, but this still requires significant overhead). This is presumably due to the incomplete Language Server impl provided by the Godot Engine.

I can see two ways around the first constraint rn:

1. Just straight up make the monorepo a Godot Engine project, and set up a pre-commit script to add a .gdignore file to every non-root directory not specified in some file (gdincludes.txt?). This is probably the simplest solution but would add a bit of unavoidable clutter to the monorepo
2. Godot development lives in a fork of the main monorepo (cusorless-dev/cursorless-with-gdscript?), which has the root of the monorepo inside of a Godot project, with changes from the main monorepo mirrored in the fork but not vice-versa. A separate version of the cursorless-vscode plugin for gdscript development is shipped as well until either https://github.com/godotengine/godot-proposals/issues/11056 is closed with an improved language server, or an in-engine Cursorless implementation is well-developed enough that gdscript support development can be retooled to not require vscode at all.

Regardless, the second constraint will require spinning up a headless version of the latest stable Godot Engine and opening the project when running tests, and will require developers working on gdscript support to do something similar on their end.

[AndreasArvidsson]

I just tried this pull request and if I added a supported scope and ran "Cursorless record scope" for gdscript it worked fine. Note that I don't have geequlim.godot-tools installed.

[rinOfTheStars]

...well, that's just a little bit baffling. If running the tests once I have everything set up works as expected w.o the plugin, then I guess that solves the issue lol

[AndreasArvidsson]

To actually run the tests we need a language definition for gdscript, but that is not necessary during "Cursorless record scope"

[rinOfTheStars]

Right. Do we just need the language definition or is the language server also needed? I can look into writing a very bare-bones vsc plugin for the former case, but if the language server is needed in any way then I'll need to come up with a solution to the whole "needing to be a Godot Editor project" issue

[AndreasArvidsson]

We only need the language definition. The rest we get from Tree sitter.

Maybe we should just create a cursorless-dev extension that has all of the language definition needed for testing. In that case we could remove several other extensions from our sandbox.