Refactored themes into simple build

[Zearin]

Motivation

I wanted to add some more colors for ReST, and I got annoyed that I had to hunt to find the single existing rule for ReST within a large file.

I also noticed that the rules for Markdown were not all together; they were split up into two different parts of the theme.

We can do better!

Changes

• Split up the rules for each language under src/
• Replaced all Solarized color values with __«VARIABLE»__
• Added a simple build.sh script that concatenates the files for each language together, then replaces all the variables with their Solarized color values

Benefits

• Less intimidating/tedious to work with source
  • Easier for contributors to to add a new language
  • Easier for contributors to spruce up their favorite language
  • No more looking up color values; intuitively write __RED__, and you’ll get Solarized red
• Language rules are now always contiguous in the built .tmTheme file (no more “Markdown rules … other rules … more Markdown rules”)
• Nonstandard colors—normally unwanted, but occasionally useful—are now obvious

[deplorableword]

Neat, so the build.sh pulls in all the files and sets the correct hex values? Could you add a Readme which explains how to someone can make changes or add support for a new language?

[Zearin]

Neat, so the build.sh pulls in all the files and sets the correct hex values?

Yepper! :D

Could you add a Readme which explains how to someone can make changes or add support for a new language?

Sure! Gimme a few…

[Zearin]

Alright!

Updated the main README, added one under src/.

[jibsen]

Good idea.

I wonder if something slightly more platform independent like perl or python might be better than a bash script?

Also, I guess ideally the light and dark themes should be the same with the base colours swapped. If that is the case, perhaps you could build both from one set of source files?

[deplorableword]

well textmate 1/2 only runs on recent-ish OSX so anything which will run
without any version conflicts or requirements to install would be good with
me. bash seems to fit the requirements for that

I don't believe the sublime fork takes any changes from us anymore, so as
long as there is always the latest complied version checked in, then it's
good with me 👍

On Friday, 11 April 2014, Jørgen Ibsen [email protected] wrote:

Good idea.

I wonder if something slightly more platform independent like perl or
python might be better than a bash script?

Also, I guess ideally the light and dark themes should be the same with
the base colours swapped. If that is the case, perhaps you could build both
from one set of source files?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/59#issuecomment-40250321
.

Tom Martin
twitter.com/deplorableword
devart.org

[Zearin]

I wonder if something slightly more platform independent like perl or python might be better than a bash script?

Textmate is OS X only, which always has bash, so…

Also, I guess ideally the light and dark themes should be the same with the base colours swapped. If that is the case, perhaps you could build both from one set of source files?

Probably! It occurred to me, but I wanted to see whether this PR would be well-received before I spent more time refactoring.

How bout it, @deplorableword ?

[jibsen]

Ah, I didn't realize Textmate was OS X only, good point.

[Zearin]

Okay! I just updated, and now there are no more *.dark and *.light files. The build.sh script will now swaps the 4 base colors to generate the Light theme.

Anyone else want to try it out and let me know how it goes?

[deplorableword]

Neat, I will give this a spin

As an aside, one of the reasons why developing this is so tedious is the constant need to re-load the theme into TextMate. At the end of the build we could trigger something to re-load TextMate the latest current theme? AppleScript perhaps?

Might not be possible or simple, but would improve the workflow for sure.

[Zearin]

As an aside, one of the reasons why developing this is so tedious is the constant need to re-load the theme into TextMate. At the end of the build we could trigger something to re-load TextMate the latest current theme? AppleScript perhaps?

Oh, I’ve been thinking about this a lot. I don’t know anything for certain yet…but I do have an idea.

TextMate bundles are incredibly powerful and flexible. If you open the Bundle editor (Bundles ▶︎ Edit Bundles…) and look through them, it looks like TextMate can run literally any script, in a variety of programming languages.

Theoretically, it should be possible to:

• write a script that allows TextMate to “refresh” itself after tweaking a theme
• write a script that can “rebuild” the 2 Solarized *.tmTheme files from within TextMate

Until then, I’m still doing things manually. Although there is one keyboard shortcut that automatically restarts TextMate: ^⌘Q. (It’s unlisted in the application menus. I discovered it in the “Select Bundle Item…” panel by accident.)

So, if you’re testing the Solarized build, you can drop the themes in using the Finder, then go back to TextMate and hit the keyboard shortcut. It quits, then automatically restarts.

[deplorableword]

Yeah I guess we could write a bundle so you could hit a key inside TextMate to build then restart, getting a bit meta :)

I don't have a copy of TM1 to hand, but I think there used to be a Theme Development bundle which actually re-loaded the theme? Not sure if this did a full restart. Possible that the command doesn't exist in TM2 anymore anyway.

If we are using the command line to do a build, then could we add something like
osascript -e 'tell app "TextMate" to quit' && osascript -e 'tell app "TextMate" to activate' which will quit and restart automatically :)

[jibsen]

I posted about this in braver/Solarized#16, but since it relates to this pull request as well, I made an example branch off your work to show how this theme could also be generated using yamltotm:

https://github.com/jibsen/textmate-solarized/tree/yamltotm_build

Your script already does most of this of course, the only added benefit is that YAML is easier to work with than XML.