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

match_brackets: add heuristic when matching starts with $ char #4259

Closed
wants to merge 1 commit into from

Conversation

alevinval
Copy link
Contributor

When editing a variety of different types of files (eg. YAML) there's usually support for variable interpolation, this usually comes in the form of ${var}. For the case of YAML, this is not specially recognized since it's not part of the spec. Imagine the following YAML:

key: ${value}

According to the YAML spec this is simply a string scalar node, which TreeSitter correctly recognizes. Users that try going to the matching bracket may find the behaviour confusing, because nothing happens.

This patch runs a small check, in which if the syntax node starts with $ then it skips to the next character, worst-case scenario it's not a recognized bracket, and best case scenario a supported bracket.

When editing a variety of different types of files (eg. YAML) there's
usually support for variable interpolation, this usually comes in the
form of `${var}`. For the case of YAML, this is not specially recognized
since it's not part of the spec. Imagine the following YAML:

```yaml
key: ${value}
```

According to the YAML spec this is simply a string scalar node, which
TreeSitter correctly recognizes. Users that try going to the matching
bracket may find the behaviour confusing, because nothing happens.

This patch runs a small check, in which if the syntax node starts with
`$` then it skips to the next character, worst-case scenario it's not
a recognized bracket, and best case scenario a supported bracket.
@alevinval alevinval marked this pull request as draft October 13, 2022 22:08
@dead10ck
Copy link
Member

I'm not in favor of adding hardcoded character exceptions like this for the benefit of one particular markup language.

@alevinval
Copy link
Contributor Author

alevinval commented Oct 14, 2022

I totally agree with you. I'd recommend to close the issue #3614, I believe there is nothing more to investigate there.

@alevinval alevinval closed this Oct 14, 2022
@alevinval alevinval deleted the issue-3614 branch October 14, 2022 07:01
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.

2 participants