Sublime Forum

Extend and replace built-in syntax definition

#1

In a .sublime-syntax file, is there a way to extends a built-in package and also replace the existing syntax?

I want to extend the built-in CSS syntax. Right now, I have a ~/Library/Application Support/Sublime Text 3/Packages/CSS/CSS.sublime-syntax file. This overwrites the built-in CSS.sublime-syntax file, as expected.

However, if I use extends: Packages/CSS/CSS.sublime-syntax, the app hangs in the YAML parser and has to be force quit.

I’d like to do something like:
extends: Sublime Text.app/MacOS/Packages/CSS/CSS.sublime-syntax.

Thanks!

0 Likes
#2

When you replace a package file like that, you’re overriding it; that means that the version of the file as it exists is wholly ignored in favor of yours.

As such, no, there is no way to do that such that you extend your syntax from the existing one and also replace it.

However, since by doing that you’re replacing it, there is no need to extend it; just modify it directly to have the extensions that you want.

If you want to have a smaller extension file, then you want to create your own syntax that extends, keep it in your User package, and then use View > Syntax > Open all with current extension as... while you have a CSS file open to associate your syntax with CSS files instead of the built in one.

0 Likes
#3

Thanks! Using the smaller extension file and Open all with current extension as... gets me 95% of the way there.

It’s a bit confusing to figure out which “CSS” is being used, but I can change the name to “CSS *” or something similar. That said, I do wish it were possible to hide the original “CSS”.

0 Likes
#4

I had this exact question, and hopped on here to find the answer… and look who already asked it for me! Hi Ricci!! :smile:

I agree, it would be very nice to allow an extends syntax in the User folder to declare itself the de-facto syntax for a given extension, while leaving the Default syntax file in place to extend from. I guess it’s time to create a GitHub issue…

0 Likes
#5

Even though it is a bit of a special case described, there’s a feature request for something like that at:

A functionality like that would however need to be used with care, as syntaxes might mess up quickly, if various packages try to extend them in arbritary ways.

Another idea how to do something like that is discussed at

Introducing a concept of “dialects” is inspired by

0 Likes