Skip to content

Conversation

rinOfTheStars
Copy link
Contributor

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 >.<

@rinOfTheStars rinOfTheStars requested a review from a team as a code owner October 11, 2025 21:07
@AndreasArvidsson
Copy link
Member

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

Copy link
Member

@AndreasArvidsson AndreasArvidsson Oct 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a big fan of committing an empty file. Please add at least one scope to it. You can do something simple like comment for example.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Going to need to make another PR to add another codium cli naming related fix first so I can more easily do that, but once that's done that should be easy enough

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See #3093 for the fixes mentioned above

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't follow why you would need to update the scripts first? Personally I don't use those scripts at all.
You just run the Cursorless extension from inside of vscode/codium when developing.

Copy link
Contributor Author

@rinOfTheStars rinOfTheStars Oct 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's required in this very specific instance because gdscript isn't supported by prod yet, and I can't get developing from the cursorlessDevelopment dev profile to work for some reason. Probably need to delete and remake the thing?

I can probably bootstrap a local version using the scripts update I made by building from this PR, at the very least, so getting that PR in isn't urgent for now

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would definitely recommend getting the development profile working. That will hot reload and apply any changes whenever you save a scm file.
Removing the profile/sandbox and installing it again sounds like something to try.

@rinOfTheStars rinOfTheStars marked this pull request as draft October 18, 2025 18:18
@rinOfTheStars
Copy link
Contributor Author

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
Copy link
Contributor Author

rinOfTheStars commented Oct 18, 2025

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 Refactor the GDScript Language Server to improve maintainability godotengine/godot-proposals#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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants