Closed zachallaun closed 1 year ago
Thanks for the fix, I didn't know about this quirk of bracket matching!
I didn't either until yesterday! I randomly noticed some brackets matching incorrectly while browsing the Lexical codebase and thought I'd take a crack at fixing it. I actually can't find this documented anywhere, but I eventually found this 6 year old comment that explained it.
Absolutely, as little thought as possible has been given to the grammar so far, I'm sure there are a lot of ways it could be improved.
Fair enough! I may take a pass through it and see what can be tidied up at some point later. Out of curiosity, was the current grammar based on an existing reference? Like whatever Elixir LS does/etc.?
Yeah it's the same grammar as Elixir LS iirc.
What I think would be best is if we could convert the official tree-sitter grammar to TextMate. I've no idea if this is feasible or how hard it would be, but it would mean we don't ever have to maintain it.
Some quick research on "tree-sitter to textmate" doesn't yield anything though, so it's probably not so easy :sweat_smile:
VS Code supports build-in bracket matching, highlighting matching pairs and supporting features like go-to-matching-bracket. To differentiate between significant and non-significant brackets (e.g. those in strings), VS Code looks for a
string
segment in the token name.A lot of "string-like" Elixir syntax didn't have that
string
segment, which is added in this commit.The approach I took is to append
string
as far towards the end of the name, but beforeelixir
, so that as much existing syntax highlighting remains the same. (Syntax highlighting rules use a prefix match.)I believe that some names could be replaced entirely for more accurate ones, but I don't think they should be changed at this point for compatibility reasons. (For example,
support.function.variable.quoted.single.string.elixir
should probably just bestring.quoted.single.elixir
.)Before (note the incorrect paren matching):
After: