Handle subscopes differently/better?

Just saw that you’re flattening scopes… why not preserve them?

IE: title.function becomes just “title” and “function” separately, which isn’t really the same thing at all.

It seems like you’re purposely losing data… and I’m not sure the benefit since you don’t have to care about CSS or anything…

[joshgoebel]

Since 3rd party grammars can technically use whatever scope names they desire it seems more than theoretical and I didn’t want a disclaimer explaining that you can’t have both a.b.c and c.b.a without things breaking badly. We also already have real conflicts with 3rd party themes (or custom themes) that use the old style function and class scopes vs the newer title.function and title.class… these are not always even semantically the same things.

Sometimes class and function were used to refer to the entire class definition or entire function body… applying the class scope coloring to title.class would be entirely incorrect in those cases. Hence needing a way to differentiate top-level class from the more nuanced (and potentially entirely different semantic) title.class.

This is also partly related to semantic versioning and my desiring to solve this problem completely the first time rather than find out in the middle of the v11 cycle that there are cases where it breaks badly and then needing a breaking change to fix things properly. As you know it’s also fairly simple for someone to hack into the parser if they TRULY need a simpler output and are confident that the CSS scope overlapping problem is one they are -guaranteed- to be safe from.

That said, I haven’t heard from anyone having any real issues with this system at all since it’s release. 😃

[joshgoebel]

I don‘t see a practical reason to differentiate between .title.function and .function.title on a span.

As I think I mentioned not a great example… sub-scopes are meant to be hierarchal (exactly like TextMate scopes) and hence in the abstract a.b.c is NOT at all the same scope (at all) as c.b.a - and possibly should be highlighted entirely differently… so the system was designed to correctly preserve this hierarchal nature even down into the CSS layer.

No one’s reported any real issues with the approach yet, other than that it’s perhaps a bit unfamiliar looking. 😃

Glad you got it fixed though!