As a software engineer, I spent most of my time in text editor and terminal. I use Hyper for my terminal app and Atom as the text editor. For quite some time, I used Atom Material UI theme and One Dark syntax theme in Atom.
Then I found someone sharing their editor (not Atom) on twitter and suddenly my editor theme looks ugly.
My first instinct is to search for alternatives because I was lazy and I thought making my own syntax theme is difficult. Turns out I was wrong.
Style Override
Having built on top of Electron makes Atom essentially a glorified website, and I mean that as a compliment. It's really easy to fiddle around with the style by opening the Dev Tools by pressing Cmd+Alt+I on Mac, just like what you do when debugging style in the actual website. Changing styles via devtool is not going to last, so I need a more permanent solution.
Atom has a feature called style override, where you can add a style to override original style (you don't say). You can do that by clicking Atom in the menu bar and click Stylesheet. Atom will open a new file for you called style.less (of course it is) that you can edit to adjust your editor style. As you might know from the extension, Atom use LESS as a CSS preprocessor. It's basically a CSS with extra syntax for variables etc.
The file itself is already have an example that you can edit easily. To apply the new style, you can press Cmd+Alt+Ctrl+L. Yes, that's 4 key combination.
Making Your Own Style
After finished tweaking my new styles I was thinking of sharing it. I searched for how to publish your own theme, and turns out it's pretty easy.
Atom has a template generator that you can use to bootstrap your project. Press Cmd+Shift+P and choose Generate Syntax Theme. After that you will be asked the name of your theme and the directory to put your files. In the background Atom will create a symlink from ~/.atom/packages directory to your previously-created directory. Next time if you want to rename or move the directory, you can readjust the symlink yourself.
There's only three main files you need to know: base.less, colors.less, and syntax-variables.less. colors.less and syntax-variables.less are both a variable declarations only. You don't need to edit all of them to achieve the theme that you want. But, all of those three files will be required in the main index.less so keep in mind when you have problem assigning variables.
Here's the result of my syntax theme. As I mostly use the editor to edit JavaScript and CSS, I only optimize the style for those 2 languages.
So, how do I decide which color for highlighting what? When I was designing the new syntax theme, I have some principles that I used to determine how to style things. I think these principles are really useful in designing a good syntax theme
Beauty
This is the primary reason they exist. A syntax theme should be pleasing in the eye. I know it's subjective, that's why there's so many of them to choose from. I'm by no means an expert in color theory, so I just use the best looking color combination I know, which is colors from hyper-snazzy. Thanks, Sindre.
Distraction Free
The next aspect to consider is distraction. What I mean by considering distraction is that, the usage of the color variance should be minimal. It's possible to assign every string token as different color and still look beautiful, but it will be distracting. So how do we design a non distracting theme?
My approach is by analyzing specific content first. In JavaScript, for example, we will be using a lot of variables and object property / accessor, while in CSS we'll be writing a lot of values. By knowing the occurence, we can then assign those types of token with warm and neutral color (white-ish / light yellow).
Sometimes a little bit distraction can also be useful though. For example, string literal is a sign of possible hardcoded value, so we need to display them in more prominent color.
The next step is to minimize less useful element. In both JavaScript and CSS, curly braces appear quite often but we didn't actually need to syle them with attention-seeking color. That's why I think it's better if we style them with color that blends more with the background. Besides curly braces, any type of punctuation can sometimes be a little bit distracting, so I use the same style to reduce the highlight.
Comment is also a part where you only need to know they exists. After all the good code is the self documenting one. It should be readable though.
Clarity and Consistency
Good syntax theme should provide clear and meaningful color. This is useful to manage expectation from the users. Similar type of string should have similar (or if not same) color.
For example, in my case I use magenta to highlight the native syntax declaration in JavaScript such as import, const, function, and return statement. I use lighter version of magenta for keyword and operator, in a way that shows that it is still a native syntax.
For constants value, is use orange. For native builtin objects/values, I use lighter version of orange because it's kind of a constant value. I use light blue for function call and method so that I can skim over codebases faster.
Adaptability
Considering the quirkiness of JavaScript, it's possible that you ended up in two different syntax that does the same thing. A good syntax theme should know this and use consistent color in both cases.
For example, where you have to create an object literal. To define a property you can use string without quote. You can also define them with quote, or you can even write them with object property shorthand notation. A good theme should know these possible outcome and styles accordingly.
Another thing to consider is how it would be used. For example, regex is better styled with the same color as constant declaration, because they both show a constant value, that is, it's not going to be changed after declaration.
There's actually another important thing to consider, which is accessibility. If you decide to design syntax theme for other people, make sure you consider this aspect. I was privileged to be able to see different colors, others might not. Honestly I didn't think about it when I created this syntax theme, because I only use it for myself, and only published it so others can use as well.
What do you think? If you want to provide feedback, you can do so by creating an issue in the github repository.