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

Improved kotlin syntax based on latest documentation #137

Closed
wants to merge 5 commits into from

Conversation

per-steinar
Copy link

@per-steinar per-steinar commented Oct 26, 2023

Improved syntax based on documentation from https://kotlinlang.org/

Summary

  • Improved scopes for imports
  • Separating val and var
  • Improved capturing of functions and parameters
  • Added variable and object capturing
  • Added capturing of keyword for mapping
  • Added capturing of optional accessor
  • Added capturing of elvis operator

See: eclipse-buildship/buildship#1273

@themkat
Copy link
Contributor

themkat commented Nov 24, 2023

@fwcd , this PR is almost a month old now. Any chance to look at it soon? I don't really have many permissions in this repo. Seems quite reasonable to me though 🙂

@per-steinar
Copy link
Author

@fwcd I have added some screenshots to redhat-developer/vscode-java#3407

Copy link
Owner

@fwcd fwcd left a comment

Choose a reason for hiding this comment

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

Thanks! Left some quick thoughts below

syntaxes/kotlin.tmLanguage.json Outdated Show resolved Hide resolved
}
},
"variable-declaration": {
"match": "\\b(val|var)\\b\\s*(?<GROUP><([^<>]|\\g<GROUP>)+>)?",
"match": "\\b(var)\\b\\s*(?<GROUP><([^<>]|\\g<GROUP>)+>)?",
Copy link
Owner

Choose a reason for hiding this comment

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

The separation of var and val is interesting as it lets us highlight constants differently.

On the other hand, I worry that this duplication will increase the maintainance burden. In general, I think "being liberal" about allowing the same syntactic constructs for var and val should be fine for syntax highlighting.

Curious to know how other languages handle this.

Copy link
Author

@per-steinar per-steinar Jan 15, 2024

Choose a reason for hiding this comment

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

To be honest, I'm not sure where I got the idea to create a separate scope for val. I have checked how the TypeScript grammar handles this, and it combines let, const and var.

C# uses readonly scope, but only for the readonly keyword https://github.com/microsoft/vscode/blob/83127004a87124b1b8b976b9f9022da41814dfd0/extensions/csharp/syntaxes/csharp.tmLanguage.json#L3034

On the other hand, both BuildShip and the RH Java Extension accepted this, so it is up to you if I should revert it.
https://github.com/eclipse/buildship/blob/0800e1c1ea25a3afca2a113a0747efe822a65273/org.eclipse.buildship.kotlindsl.provider/kotlin.tmLanguage.json#L445

Copy link
Author

Choose a reason for hiding this comment

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

I have searched a bit more, and I added the readonly distinction because of the "Semantic Highlight Guide" documentations for VSCode mentions it.
See: https://code.visualstudio.com/api/language-extensions/semantic-highlight-guide
image
However, it does not look like it is common to be used for the const/val keywords, only for the readonly keyword.
I can revert the change, it you prefer.

I have also made some changes to the definitions for val/var to be more in line with how the java grammar handles local var.

I may be a bit biased when I'm using the Java grammar for guidance, but I'm only using Kotlin in conjunction with Java, so that's what i know.

@@ -19,10 +19,13 @@
],
"repository": {
"import": {
"begin": "\\b(import)\\b\\s*",
"begin": "\\b(import)\\b\\s*([\\w+.]*\\w+)?\\s*",
Copy link
Owner

Choose a reason for hiding this comment

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

Hm, I am not entirely convinced this rule is correct. This will match the package too in imports and highlight it as if it were a modifier:

image

For comparison, this is the current state which, IMO, is more correct:

image

Copy link
Author

@per-steinar per-steinar Jan 15, 2024

Choose a reason for hiding this comment

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

I cannot reproduce this. I have tried with both my fork of the extension and by creating an empty extension with only the grammar from the PR:
image

Edit: what is the scope of the parts in green (Before, Test etc.)?

Copy link
Owner

@fwcd fwcd Jan 15, 2024

Choose a reason for hiding this comment

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

Yes, your color scheme is different, but the package shouldn't have scope storage.modifier.*. If you enable the Dark+ or Dark Modern scheme, you should get the same result.

The green parts are semantic tokens provided by the language server, not by the grammar:

image

Copy link
Author

@per-steinar per-steinar Jan 16, 2024

Choose a reason for hiding this comment

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

I have looked on how the java grammar handles this. It looks a bit more sophisticated than this. I am not sure if I will be able to fix it this week

Edit: I have pushed an update to the definitions to be more in line with the scoped used by the Java grammar bundled with VSCode:
image

@fwcd fwcd added the grammar Related to the TextMate grammar, i.e. syntax highlighting label Jan 15, 2024
}
},
"variable": {
"match": "\\b(\\w+)(?=\\s*[:=])",
Copy link
Owner

Choose a reason for hiding this comment

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

This isn't quite right either, this will match anything on the left-hand side of == too, including e.g. numbers:

image

Anything involving = will likely require being very careful to not accidentally match any equality operators. This includes cases where e.g. the space is left out, i.e. expressions like (x!=3)...

Copy link
Author

Choose a reason for hiding this comment

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

I'm removing this definition completely. It need a bit more work to be implemented correctly.

@per-steinar per-steinar force-pushed the improved-syntax branch 2 times, most recently from 3535583 to eb7c3a3 Compare January 16, 2024 17:02
Update syntaxes/kotlin.tmLanguage.json

Our suggestion is the same as the one in the built in definition for java, so I guess it's the proper way to do it
https://github.com/microsoft/vscode/blob/12443ca030f93843ca5e9dfb5682ad92d2c6400c/extensions/java/syntaxes/java.tmLanguage.json#L53

Co-authored-by: fwcd <30873659+fwcd@users.noreply.github.com>

Removed definitions for reassigning varaibles
@per-steinar
Copy link
Author

Thanks for all the feedback. I have tried to fix the issues you have found.

@fwcd
Copy link
Owner

fwcd commented Jul 28, 2024

Please rebase onto the latest main branch, #150 made some minor changes to the way keywords are highlighted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
grammar Related to the TextMate grammar, i.e. syntax highlighting
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants