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

Add entity.name.type.zig to container_decl. #65

Closed
wants to merge 2 commits into from

Conversation

Manuzor
Copy link

@Manuzor Manuzor commented Aug 9, 2022

This way, unions, structs, enums, and error declarations get properly marked as types so that "go to definition" works properly in sublime text.

I tried to follow the "Local Development" section in README.md, but just editing the Zig.YAML-tmLanguage file and using PackageDev to convert it didn't update the sublime-syntax file, which is apparently what sublime text prefers if it finds one, ignoring the tmLanguage version. So I edited the sublime-syntax version manually until things worked as expected, and transferred my changes to the YAML-tmLanguage file. Then I invoked the PackageDev Convert To ()... command but that only produced a tmLanguage file. The tmLanguage.json did not get updated. At that point, I was too confused by all this, being quite new to all this, so I figured I'd just get a PR going and ask for guidance.

Fixes #64

Manuzor added 2 commits August 9, 2022 17:19
This way, unions, structs, enums, and error declarations get properly marked as types so that "go to definition" works properly in sublime text.
Otherwise sublime picks up simple usages of a type, such as Hello in `const foo = Hello.foo_value;`, as type declarations.
@Manuzor
Copy link
Author

Manuzor commented Aug 10, 2022

I've added a second commit that assigns general type matches (everything ending with _t or starting with an uppercase letter) the scope storage.type instead of entity.name.type. Otherwise sublime will think those are supposed to be type declarations. And besides, this is the same scope that is used for function return types, for example, so it seems more appropriate for that reason as well.

If you want me to split those two commits into separate PRs, or if you think this is wrong, please let me know! Thanks.

@gwenzek
Copy link
Contributor

gwenzek commented Aug 10, 2022

You shouldn't try to do conversion between the tmLanguage and sublime-syntax files. Tmlanguage is just there for people that would be using a very old version of ST for some reason.

About the changes themselves, there should only be exactly one "entity.name" scope at the time, so I don't think this is the right way to solve the issue. I'll look into that.

@gwenzek
Copy link
Contributor

gwenzek commented Sep 2, 2022

can you try #67 ? I had those sitting for quite some time on my fork, I forgot I never pushed them.

@Manuzor
Copy link
Author

Manuzor commented Sep 5, 2022

I haven't come around to test this thoroughly yet but it seems to fix #64 as well as some other issues I tried to fix locally. Thanks!

Closing because #67 supersedes this PR.

@Manuzor Manuzor closed this Sep 5, 2022
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.

Symbol detection gives incorrect locations
2 participants