-
Notifications
You must be signed in to change notification settings - Fork 40
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
[Suggestion] Add try
to keywords, and remove try
, try?
and try!
from the operators.
#351
Comments
This seems reasonable in the abstract, although it’s hard to say for sure without screenshots. I can probably find some time to experiment with this the weekend after next; if you have time for a PR earlier than that then I’ll happily review. |
Thanks for considering it. No rush, either way. I'll try and make a PR, or share some screenshots or something, soon. Thanks again. |
Hey, @alex-pinkus. I had another look at this, and found a handful of issues. If I understand correctly, most (all but one) are upstream of this project, but I'll reiterate here, so you're aware at least (and I may be wrong):
Adding I wasn't able to experiment with highlighting |
Thank you so much for this thorough analysis! At a quick glance I think all of these are on me — the base tree-sitter only gives us some infrastructure for parsers but all of this is work needed on the grammar. I’ll try to find some time to add support for if- and switch-expressions — that one seems most likely to require meaningful grammar changes. Separating try from its punctuation shouldn’t be too hard; if I recall, I special case those as tokens and can just change to token + immediates. If you’re interested I could probably provide enough guidance to show you how to do that or others as a PR (if-expressions is the only one that I think is too tricky to take on as a first issue). |
And if you’re updating |
No problem. I see. I don't understand how everything fits together. I'd be happy to dive into it more, but need to revisit the TreeSitter docs and better understand how everything works. I'll make a PR for the Note: I only added Thanks again, mate. Much appreciated. |
I was just looking through some of the other open issues. They're generally all issues for me/Helix too. Once I understand how TreeSitter works better, I'll try and help you close a few. |
As pointed out in #351. [SE-0380](https://github.com/apple/swift-evolution/blob/main/proposals/0380-if-switch-expressions.md) made it possible to do this, but support was lacking in this repository. The fix turned out to be easier than anticipated, simply requiring the statement to be added in some new places. Theoretically, it should also be renamed, but that would make this a breaking change. The proposal does not make clear whether labels are permitted on expression-position `if` and `switch` statements. This assumes they are not, for simplicity.
As pointed out in #351. [SE-0380](https://github.com/apple/swift-evolution/blob/main/proposals/0380-if-switch-expressions.md) made it possible to do this, but support was lacking in this repository. The fix turned out to be easier than anticipated, simply requiring the statement to be added in some new places. Theoretically, it should also be renamed, but that would make this a breaking change. The proposal does not make clear whether labels are permitted on expression-position `if` and `switch` statements. This assumes they are not, for simplicity.
I haven't forgotten. I just didn't realize I had to install Node, so I'm experimenting with connecting to GitHub Codespaces (from a local VSCode installation), and doing PRs that way. |
I gave this a go, and got a bit stuck with it. I thought I just needed to update I added The tree-sitter tests match a Swift string to its S-expression AST, and that's when I realized that the parser will need to know that |
So you're on the right track, but you actually don't need to mess with Since your goal is to test I can create a PR real quick for your |
In helix-editor/helix#9586, the Helix editor added highlighting for the `any` keyword. However, while reviewing that, I noticed that both `some` and `any` should be more specific: these keywords are legal as identifiers, but should not be highlighted as identifiers when they are keywords. For instance, I can write: ``` let any: any Protocol = AnyImplementation() ``` In this example, only the second `any` should be highlighted. See discussion on #351
WIP. It should be possible to have `token.immediate` behavior for this; currently an expression where `try` is lifted to the top level and followed by a negation will mis-parse. See #351
I see. I think I get it now. I was looking through the stuff you mentioned.
Cool. Yeah, If you don't mind. That'd be helpful. It'd also be nice to know it's done, and I can spend a bit of time looking through the code, and the other issues. Nice one, buddy. Thanks again. |
In helix-editor/helix#9586, the Helix editor added highlighting for the `any` keyword. However, while reviewing that, I noticed that both `some` and `any` should be more specific: these keywords are legal as identifiers, but should not be highlighted as identifiers when they are keywords. For instance, I can write: ``` let any: any Protocol = AnyImplementation() ``` In this example, only the second `any` should be highlighted. See discussion on #351
I had some free time to address all of the issues you listed above; many of them ended up being a bit more involved than just changing highlight queries so it was probably for the best that I did it. Feel free to submit a PR with any additional enhancements you come up with. |
Nice work, Alex. Well done, mate! You're an awesome maintainer. I'm still keen to improve Swift support in Helix, and looking forward to contributing to your project along the way. |
Xcode highlights
try
as a keyword, and highlights?
and!
as operators. I think that works better, but it's kinda subjective.The text was updated successfully, but these errors were encountered: