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

Support for new bracket colorization in 1.60 #5

Merged
merged 2 commits into from
Oct 28, 2021

Conversation

runxel
Copy link
Contributor

@runxel runxel commented Sep 6, 2021

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.)

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)).
@pbaksa
Copy link
Contributor

pbaksa commented Sep 9, 2021

  1. This conflicts with range [, ) The closing ) will be red as if it is an error. The highlight can be turned on/off, so there is nothing against allowing it.
  2. Sometimes [] are nested too. I find it useful to see them distinguished.
  3. With command{2} the theme coloring has precedence, {} isn't highlighted, so maybe we can get away without specifying a language rule.

@runxel
Copy link
Contributor Author

runxel commented Sep 9, 2021

1. This conflicts with range [, ) The closing ) will be red as if it is an error. The highlight can be turned on/off, so there is nothing against allowing it.

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.

2. Sometimes [] are nested too. I find it useful to see them distinguished.

Sure, I can add them to the list in the PR.

3. With command{2} the theme coloring has precedence, {} isn't highlighted, so maybe we can get away without specifying a language rule.

Not entirely, sadly! I wish, but my main concern are angled brackets <>. The devs of VSC decided stupidly to not exlude them by default. Instead they are highlighted too.
I made this PR so I can avoid to have them styled.

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)
@pbaksa
Copy link
Contributor

pbaksa commented Sep 15, 2021

How is <> problematic? I tried but didn't get them colored with VSCode 1.60.1

@runxel
Copy link
Contributor Author

runxel commented Sep 15, 2021

@pbaksa Huh, seems it's already fixed? I also don't get it colorized now.

Copy link
Contributor

@pbaksa pbaksa left a 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.

@pbaksa pbaksa merged commit 516b47b into GRAPHISOFT:main Oct 28, 2021
@pbaksa pbaksa added the enhancement New feature or request label Nov 2, 2021
@pbaksa pbaksa added this to the v25.2 milestone Nov 2, 2021
@runxel runxel deleted the brackcol branch February 12, 2023 23:42
pbaksa added a commit that referenced this pull request Feb 14, 2023
# 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.
pbaksa added a commit that referenced this pull request Sep 27, 2023
* deleting onEnterRules, conflicts with paste and moving lines
* subroutine snippet: header 100 characters wide
* dev version
* don't indent after commented keywords
* upgrade vsce
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants