".sublime-color-scheme"?

[ngppgn]

I’ve seen in the changelogs that a new “.sublime-color-scheme” format, but can’t find any extensive documentation on it, nor any files in the sublime installation with the format so I can learn from example. Does someone have any documentation, or an example file that illustrates how it works, compared to .tmTheme? (I’m assuming these two formats fullfil the same role, but please correct me if I’m wrong).

[kingkeith]

the docs at
http://www.sublimetext.com/docs/3/color_schemes.html
apply just with a few differences mentioned at

Dev Build 3149

Dev Build 3149 is out now at https://www.sublimetext.com/3dev The first change in 3149 is selectionForeground coming back better than ever: it can now be specified on a per-rule basis, so you can now have both a high-contrast selection, and still have syntax highlighting. An a minimal example, you may want to change your selection color to something bright, and then edit all the rules with colors close to the selection color, changing them to use a different foreground color when selected. …

(and some small tweaks in the later dev builds)

[ngppgn]

There must be a confusion somewhere. The link you provided documents the .tmTheme format, not the .sublime-color-scheme format.

And while the second link explains some things, I can figure out how to build a whole color scheme in sublime-color-scheme format just from that.

[wbond]

There is no full docs yet as the format is in flux as it is being developed. I’ll likely write up docs for it soon.

[ngppgn]

Thank you very much

[tajmone]

I’m currently developing a custom ST3 package that uses the .sublime-color-scheme format.

Could you tell me the exact build of ST3 that introduced the new .sublime-color-scheme format? I need this info to declare the ST compatiblity for the package — eg "sublime_text": ">=3000"

[ngppgn]

It was added in build 3149, it seems.

[tajmone]

Thanks @ngppgn!

So, it looks like that by using the .sublime-color-scheme format my package won’t be usable by stable ST3 users until the next stable release of ST3. Still, it might be worth it because the new format is much friendlier than the XML based one.

Otherwise, I could use PackageDev to convert it to Property Lists XML format, from the documentation it seems it can handle conversions to an from the various supported formats:

Because hand-editing XML is annoying, functionality for converting between Property Lists, JSON and YAML has been added to PackageDev.

The functionality was primarily intended for syntax definitions, but it can be used for color schemes and TextMate Preferences files alike. Even JSON files like menus can be converted to or from YAML.

• https://github.com/SublimeText/PackageDev/wiki/Serialized-Conversion

[FichteFoll]

Note that .sublime-color-scheme files support variables and CSS4 color specifications, which .tmTheme files do not (unless at least the latter was backported, which wouldn’t help you since it’d still require build 3149). Furthermore, the general structure is slighlty different with the general settings getting their own dedicated key and not being mixed inside the ‘settings’ dict anymore.

[tajmone]

Thanks for pointing this out @FichteFoll. This is the first package I’ve created, so I’m not sure which route to take.

On the one hand, I would think that targetting ST3 is better because it would make maintainance easier for me. On the other hand, the package is rather simple and doesn’t require ST3 specific features, so somehow I regret that ST2 users won’t be able to use it.

I have no idea how I could make a package work for both ST3 and ST3 while still keepig ST3 formats for ST3, I’m still going through the various documentation but I haven’t found anything on the topic.

Also, I have a ST3 license only, and I’m not sure it allows me to keep also a copy of ST2 (the licenses are different).

What would be your advice, based on experience? The syntax I’m creating targets a very small audience, and I don’t think that many users will install it anyway.

[FichteFoll]

You don’t need to worry about ST2. The user base is so small and honestly at this point they don’t even deserve the attention of package developers. I would be more worried about ST3 stable users, which is by far the largest percentage of the user base and the new format hasn’t reached a stable release yet. It will eventually, but this is a decision that you need to make.

[tajmone]

You don’t need to worry about ST2. The user base is so small and honestly at this point they don’t even deserve the attention of package developers.

Thanks for the tip, I had no idea of the current status of ST2 users. This is good news then.

I would be more worried about ST3 stable users, which is by far the largest percentage of the user base and the new format hasn’t reached a stable release yet. It will eventually, but this is a decision that you need to make.

True, but hopefully the next stable release isn’t all that far away. I guess is worth going for it. As I said, I’m expecting a very small user base for the package (mostly from an online community where we know each other); in the worst case scenario, users will fallback on a standalone ST3 Dev release in order to use it while waiting for the next stable release.

I’ll rather opt for an easier maintainance work on my side, and avoid having to reconvert the color scheme to the newer format once it’s integrated into the stable release (besides, I’ve already created two color schemes using the new format, and I really dislike working with XML based formats, it’s a huge strain on the eyes).