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.
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.
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:
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.
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
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.
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?
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.
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.
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 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.
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.