-
Notifications
You must be signed in to change notification settings - Fork 3
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
Support for new bracket colorization in 1.60 #5
Conversation
VSCode v1.60.0 has brought native support for bracket colorization. When enabled nested bracket pairs will be highlighted differently. Per this comment it has to be set up as language rule (microsoft/vscode#132336 (comment)).
|
Yes, I saw that, too. It seems that at the moment we have no fine-grained control to disable this bracket colorization for certain scopes. I think unbalanced brackets is something really unique... I can't think of any other language adhoc that has this feature.
Sure, I can add them to the list in the PR.
Not entirely, sadly! I wish, but my main concern are angled brackets Again, in the end if one never uses the bracket colorization they will see no difference so I think adding this rule is no harm. |
As per Petér's comment GRAPHISOFT#5 (comment)
How is <> problematic? I tried but didn't get them colored with VSCode 1.60.1 |
@pbaksa Huh, seems it's already fixed? I also don't get it colorized now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect they only colorize tokens which are set as bracket pairs. Looking into the bracket setting, that is usable for auto-identation, so it will make sense to colorize only some of them.
I am approving your pull request, it will be published in the extension update in a few weeks.
# This is the 1st commit message: use constants from currently edited text # This is the commit message #2: search definitions in master script search references from master in other scripts # This is the commit message #3: find other references from selected reference use extra parser for subroutine calls (don't include yet in symbols) # This is the commit message #4: use current edited version of HSF files # This is the commit message #5: Show all definitions / references, even erroneous # This is the commit message #6: use HSFLibpart to handle other scripts of libpart don't use extension setting for intellisense filtering # This is the commit message #7: Revert "use HSFLibpart to handle other scripts of libpart" This reverts commit 32463ec. # This is the commit message #8: Revert "Show all definitions / references, even erroneous" This reverts commit 1ca043e. # This is the commit message #9: Revert "use current edited version of HSF files" This reverts commit 7a04743. # This is the commit message #10: Revert "find other references from selected reference" This reverts commit 4721353. # This is the commit message #11: Revert "search definitions in master script" This reverts commit 317be45.
* deleting onEnterRules, conflicts with paste and moving lines * subroutine snippet: header 100 characters wide * dev version * don't indent after commented keywords * upgrade vsce
VSCode v1.60.0 has brought native support for bracket colorization.
When enabled nested bracket pairs will be highlighted differently.
Per this comment it has to be set up as language rule.
In this PR I've only enabled to highlight round brackets, because they are the only type of brackets, that are nested and could need a highlight.
Please note: This changes nothing as long the user hat not enabled the
editor.bracketPairColorization.enabled
setting. But if the user has enabled it, they will enjoy the correct setting.(Brackets not highlighted:
<>,[],{}
. Otherwise they would be, too. That is irritating.)