-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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 pairs which don't form a standalone TS node #7242
Conversation
ff90c6f
to
f5a3f99
Compare
also addresses #3357 (comment) (which is an unrelated bug but a small fix that makes sense to include here) I also did wind up including a (very limited) plaintext fallback to handle text-only nodes (c preprocessor nodes for example #3357 (comment)) but to not break existing workflows this only works when absolutely no other TS match it found (and only on the brackets, and within the first named parent TS node ). I am still not sure if that's really worth having since it will case brackets inside literals to be highlighted and that feels weird to me. |
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.
Ok this looks good to me, thanks!
Closes #3357
Closes #5177
These issues where caused by us requiring pairs to form a standalone TS node. This change looks at the sibling nodes (so still within the same node) to also find pairs formed by siblings. Syntax trees are usually much wider than deep, so I introduced a fairy aggressive limit on the number of examined nodes. Usually pairs form immediate siblings and looking at additional siblings is just done to handle weird grammars (and comments). The limit does lead to missing some matches but those cases are so rare that it's worth the improved performance IMO.