search

SublimeText / Sass

Sass and SCSS syntax for Sublime Text
https://packagecontrol.io/packages/Sass
MIT License
50 stars 8 forks source link

rewrite as an extension of CSS #96

Closed braver closed 5 months ago

braver commented 2 years ago

I've effectively frozen the Sass syntax as it's a ton of work, much less popular, it's even missing features from the main SCSS syntax... and users seem to be reasonable happy with it I guess. This PR rewrites most of the SCSS syntax to build upon the CSS syntax whenever possible, and borrows heavily from the work done on the Less syntax.

The intent is not to merge but to set this as the new default branch for this repo (potentially under a different name), and to make releases of it available to versions of ST > 4171. And once approved to move the entire repo into the SublimeText org.

Confirmed fixes for all open issues:

braver commented 7 months ago

For anyone following this, "recent" work on the Less package has inspired a different approach. Currently re-writing tests to match the language documentation, and step-by-step reassembling and improving each language feature. It's going to take a while, but progress isn't disappointing actually.

deathaxe commented 6 months ago

Not yet complete, and various CSS tests pending, but took some steps forward.

Split functions and mixins and try to identify more details using scopes.

May require some adjustments to symbol list and index definitions (e.g.: mixins).

braver commented 6 months ago

@deathaxe Ok if I move this repo to the Sublime Text org? GitHub's redirects should prevent breakage, but I didn't want to move it when you're right in the middle of something.

deathaxe commented 6 months ago

Yes, redirects should keep things going.

I barely can find obvious changes needed. I guess it would require some practical use and feedback to find remaining bugs.

So, feel free to move it.

If it comes to releasing...

would it make sense to freeze current master as st3 branch and squash merge commits of this PR into master?

As this PR requires CSS shipped with ST4169, I think of probably creating a ST4107 branch with that CSS bundled, to serve older releases as well with latest fixes.

braver commented 5 months ago

I barely can find obvious changes needed. I guess it would require some practical use and feedback to find remaining bugs.

At some point, we just need real world feedback. I can do some cursory checks myself, and although I've basically used SCSS daily for about 10 years, and the language itself isn't even that huge, I doubt I use half the features.

would it make sense to freeze current master as st3 branch and squash merge commits of this PR into master?

The 3.0.1 tag can remain as the final release of the old master branch. We can keep serving that for ST < 4170. It's been stable for 2 years with only minor issues.

I would then delete the old master branch, and rename this simplify branch to master. That way we retain all history.

As this PR requires CSS shipped with ST4169, I think of probably creating a ST4107 branch with that CSS bundled, to serve older releases as well with latest fixes.

Sure, that's possible, go ahead. I personally wouldn't go to that effort. I haven't released updates for two years, people can wait a bit until ST4170+ becomes stable.

I'll move some stuff around and open a PR on package control to update the entry.

braver commented 5 months ago

@deathaxe this is what happened: