Closed savetheclocktower closed 6 months ago
Is it worth reaching out to the "one of the main Tree-sitter contributors" and be so bold as to ask if they'd like to adopt your parser, or combine efforts until there's one parser that meets both of your respective sets of expectations? (I dunno if this suggestion is a little "out there", but it came across my mind.)
Anyway, good to see language support expanding for modern tree-sitter.
Is it worth reaching out to the "one of the main Tree-sitter contributors" and be so bold as to ask if they'd like to adopt your parser, or combine efforts until there's one parser that meets both of your respective sets of expectations? (I dunno if this suggestion is a little "out there", but it came across my mind.)
No, it's a fine suggestion. He knows about my parser, but he didn't see it until after he'd made his own. I told him about my test corpus and I expect him to adopt it at some point, but I also trust his solutions to some problems more than I trust my own (which are sometimes hacky) and his parser “extends” the Tree-sitter CSS parser more formally than mine does, so I think his is a better foundation to start from.
For now, though, it's not ready.
Taking this out of draft so we have time to get it reviewed before 1.117.
Getting a head start on this one.
This PR starts by adding a modern Tree-sitter grammar for SCSS. For ages, there wasn't a grammar out there that had good enough support for SCSS's features, but I forked this one a while back and very gradually fixed the things that needed to be fixed. I think it's good enough now to bundle and ship and see if there are any edge cases that need to be addressed.
A few days ago, one of the main Tree-sitter contributors made this parser, and I could see us migrating to it in the future (I don't love being a parser maintainer myself)… but it's not there yet. If it ever passes the tests that exist in my fork, then it'd be worth switching to.