Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Feather-compatible types #210

Open
thennothinghappened opened this issue Feb 19, 2024 · 3 comments
Open

Feature Request: Feather-compatible types #210

thennothinghappened opened this issue Feb 19, 2024 · 3 comments

Comments

@thennothinghappened
Copy link
Contributor

GMEdit currently uses its own type naming scheme which runs in contrast with Feather's own naming.

The main issue with this is that both can use the same JSDoc formatting for function arguments, but switching between the IDE and GMEdit will cause both to complain about eachother's types.

Some examples:

Feather GMEdit
Real number or int
Asset.GMObject<T> object or T (as asset ID)
Id.Instance<T> object or T (as instance)
Id.Buffer buffer
Id.VertexBuffer vertex_buffer
Id.Surface surface
Asset.GMSprite<T> sprite
Constant.Colour int
... ...

Solutions?

The two solutions I can think of is either adopting Feather's types, or making them aliases in some sense to GMEdit's equivalent types. The latter of these makes more sense to me as it doesn't make existing GMEdit types incorrect.

@YellowAfterlife
Copy link
Owner

I do have aliases for most of them, you can see these as fe_name in api directory and add the missing ones https://github.com/YellowAfterlife/GMEdit/blob/master/bin/resources/app/api/shared/types.gml

@thennothinghappened
Copy link
Contributor Author

Interesting, I can't seem to get those to work. I tried id.dslist for example and the variable did not show any type on hover, whereas ds_list worked.

@YellowAfterlife
Copy link
Owner

It's done with jsdoc, like so

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

No branches or pull requests

2 participants