Closed michaelblyons closed 5 years ago
I think it might be tricky to keep them separate in a way that makes sense, but sure, there is a lot of overlap. With LESS as well. So, usually I try to fix one and then sync the change to the other two. I'm behind on doing that for Sass because I don't use it myself, but usually writing the commit message is more complicated.
@michaelblyons as I understand it, it's possible to create a "common" file, and then import where needed parts from that? Starting from line 1111 it's mostly the same between the two syntaxes, so it does sound like a good idea to merge the two.
Starting from line 1111 it's mostly the same between the two syntaxes, so it does sound like a good idea to merge the two.
Neat! I think that will help with future maintainability. My ST3 doesn't seem to like my current package symlinking at the moment**, so I can't verify the work until I straighten it out. If you want, I can push my branch and you can take a look. I just don't know if it works or not. (Also, it's several commits behind master
, because the Sass and SCSS files diverged.)
** It says it can't find the Sass Common file's scopes in the index. Also true for another language I want to do this with.
@michaelblyons That's ok, I think I got the gist of it. I'll have a go, see what it does on my machine.
It strikes me that most of Sass and SCSS are the same. It might help maintenance to pull the common bits into a shared
.sublime-syntax
and have only the differences inSass.sublime-syntax
andSCSS.sublime-syntax
. Then if you add additional CSS attributes to one, they are already part of the other. See for example the Git Formats part of the default packages and its Git Common.At one point (though no longer), this was the diff of your two syntax files: