(editted) Ugh, apparently these are not in the package manger. Call me lazy but I'm not going to clone these on all four of the machines I use ST2 on. (The "ugh" seems unappreciative, that was more due to my incorrect assumption; don't mean to sound ungrateful, a couple of these look very excellent.)
Sorry, I have half a dozen color schemes in different packages that I switch between, a custom theme, several language plugins and more. It's enough work to re-install them through the package manager.
I could put them all in a folder and sync that across machines, but then they don't get auto-updated, and I'd have to use non-portable symlinks and would still have to manually update each of the likely 10 repos that I'd need to check regularly for updates.
It sounds stupid, but I have one that I'm very accustomed to to write my C, another for Golang and then one that looks much better for editting XML(-like) documents.
Sublime Text's themes are stored in /Users/.../Library/Application Support/Sublime Text 2/Packages/Color Scheme-Default (on the Mac). Just copy and paste.
I know, right? How is this missing? For Sublime on Ubuntu:
Create folder NewThemes in ~/.config/sublime-text-2/Packages/NewThemes and dump the files from the repository in there. Then Preferences > Color Scheme > NewThemes > [choose]
Tomorrow (and base16, its next incarnation) are awesome. But there's one thing I like about Pastie more: the way it highlights literal strings (and heredocs and herestrings)...
Nobody's stopping you from installing Git alongside Mercurial; even if you're not going to use it on a day to day basis, things like sublime text themes and whatnots are easily installed with a git clone.
Nice themes! It's pretty cool to see all these screenshots and the background color leaking into the tabs... I'm the designer of the Sublime Text UI theme and Jon was adamant about making the tab background using the color of the theme background color. It was really, really hard (lots of PNGs and lots of switching between PNGs depending on the luminosity of the background color, lots of pixel tweaking) and it's not perfect for all luminosity values, but these screenshots make it look pretty snazzy :)
I think these are all quite nice, however... am I the only person out there who likes comments to show up in a nice bright color (my preference, usually a bright terminal green). The faded comment look that most of these share is really hard for me to read.
I was gonna make a similar comment. All the themes I see are geared to be anti comment because of the lack of distinction in colors.
Right now I use the Tomorrow Night theme which seems to be okay but I would prefer to have a good light color scheme (the longest I ever used one was Espresso Soda theme).
That's a great point. I would love some sort of effect where if I've clicked on the comment block it is a lighter colour, otherwise it goes back to the default colour.
I prefer faded comments, because some of my code is quite heavily commented. The code itself is what I always read, and I want it to jump out at me. The comments are background info, observations, sometimes wordy descriptions of why things are the way they are, and so on. If I've been away from the code for a while, I'll read the comments to help reestablish the context, refresh my memory of failed experiments, of shortcuts, optimizations, and so on. Most of the time, I don't need to read these comments, so having them faded into the background works for me in every way except for the briefer, more urgent type of comment that SHOULD jump out.
One thing I would like to have is an editor that responded to tags within comments (so it wouldn't be a part of the programming lang syntax, but just a convention used by the programmer) which would apply different colors to different types of comments. I would then use a faded color for wordy background info or comments needed by anyone proposing to change the code but not needed for reading the code, brighter colors for brief comments on the intent of a chunk of code (making the code easier to skim) and maybe a very bright color for WARNING, or FIXME, or STUB-ONLY, or TODO, etc.
I kinda disagree; if your comments, observations etc don't JUMP OUT AT YOU READ THIS THIS IS IMPORTANT!1one, they're not important, apparently. This also goes for other people's code, really. There is often a difference between code and comments, which causes people to read the code instead of the comments. However, one cause is that comments don't draw the attention because they're often in a dimmed, 'this is not important' color scheme - the other is that there's too much comments that don't add value to the code.
It's almost like there's a law of conservation at work. The law of conservation of human attention. Comments can be used either as background hum or as salient landmarks.
> context, failed experiments, shortcuts, optimizations, and so on.
I think commit messages are the appropriate place for this stuff; I use `git annotate` etc. to find the information when I need it. I often have a 50-line commit message accompanying a one-line code change -- a ratio that would obviously make the code unreadable if all the comments were in-line with the code itself.
At http://wbond.net/sublime_packages/community (package control website), there are tons of color schemes (just search for scheme) with their corresponding github repo (most of them with screenshots to preview).
sweet ...but every time I find a new favorite color scheme, it only lasts for a week max ...after this some part of my brain pulls me into changing back to my good ol' Visual Studio-like color scheme ...wonder if this happens to anyone else too
By changing the general theme, the background color of the build panel won't change automatically (screenshot: http://i.imgur.com/35N6Z.png).
You can change the build panel's background color (in Ubuntu) by editing the ~/.config/sublime-text/\Packages\Theme - Default\Widget.sublime-settings file and replacing the current line in the file with
Dayle Rees here, glad you like my themes! If you do, please remember to star the repo! Also if you like some of the themes, but would prefer them slightly different, please let me know using the github issues feature and I will create an alternate version! Also taking requests the same way!
I like the colours, but the schemes are incomplete. Most egregiously, there is no colour setting for variables, which affects Ruby, where you want instance variables ("@foo") to be colorized.
The colorization for indent guides is much too high-contrast for me. I don't look at indent guides unless I am "lost" in a particular region of nesting.
Likewise, too much contrast for trailing spaces. Sure, I want to see when I am erroneously inserting trailing whitespace myself, but I often have to work on other people's files, and I don't such a file to light up like a Christmas tree when it's full of trailing spaces. (And usually I don't want to fix them, either. It's bad gitiquette to correct other people's bad tabs/trailing space unless you are intentionally creating a patch to fix those things.)
I use a very simple color scheme for Textmate. Basically black text on a light-yellowish background, with only string literals and comments in a subdued color. I have found that syntax highlighting with many colors distracts from the code. http://www.michielovertoom.com/incoming/textmate-colorscheme...
It's based off Soda Theme. Currently I'm using Tomorrow-Night Color Scheme, but I'm digging the Dark Green and Dark Blue too. You can also configure color of folders and tabs.
reply