-
Notifications
You must be signed in to change notification settings - Fork 11
Why Pro Colors Is Only on Visual Studio Code?
I have been in the business of syntax highlighting for many years now. From doing simple things as porting a theme to going all the way and making highlighter engines and specialized parsers for fast color tokenizations.
In my experience the whole idea of syntax coloring was till very recently very inconsistent and vague. Some editors had only simple tokenizers capable of detecting numeric values, strings and identifiers where you could define keyword colors... Some better editors offered things like function name, class name customizations, etc. It was always black text with some special words being colored. Many of the famous color themes raised from this era and they never looked consistent across editors. One editor colored function in JavaScript as a keyword, the other would color it as a declaration. Some colored variables, some didn't. In one you could differentiate between a function call and a function definition, in one they both got the same color.
Somewhere in the history of editors, comes the TextMate for macOS. While it was hardly any popular outside of a very small mac community, it forever changed the way editors implement languages. I guess TextMate paved the way for the democratization and standardization of syntax highlighting and editor compatibility. What it did was introducing two radical new file types:
-
.tmLanguage
TextMate Language file is a grammar file. It builds upon the power of oniguruma, a language definition system that extends the regular expressions and lets you colorize match groups, define starting and ending patterns, but most interestingly it enables nested grammars. All while keeping it possible for the editor to parse a line at time, or a few lines and keep the state of the rest in memory. -
.tmTheme
This is a file format that specifies which token defined by the tmLanguage should get what color
These two technologies democratizes the whole idea of syntax coloring because first of all they are incredibly customizable. You are no longer limited by the 20-30 groups defined by your editor. One can define any language and in any manner they wish. Some common terminology used by most of the grammars then makes it possible all tmTheme files work with all tmLanguage files. But then you can have themes that specifically define colors for very special tokens.
After TextMate, a revolution happened in the era of editors. We used to have 3 huge categories:
- IDEs (Xcode, Visual Studio, JetBrains, Eclipse, ...)
- Command line grandpa editors (Vi, Vim, Emacs, ...)
- Basic GUI Editors (Geany, Notepad++, BBEdit, Coda, ...)
Then came the forth category that was the combination of all the three categories. It happened when Sublime Text came, and then Atom, and finally Visual Studio Code dominated the market. What was really interesting about all the three editors was that all of them implemented TextMate in their cores. You can put a tmLanguage / tmTheme file in the Visual Studio Code or Sublime and they work. Atom is also the same, you just have to convert the file to it's desired file structure.
This made tmTheme and tmLanguage the industry standard. Now even the Visual Studio for Mac supports it.
In the age of Sublime and Visual Studio Code, I wanted to develop themes that worked everywhere. The problem at the time was two things:
-
Each editor had its own system of defining themes
-
I wanted to have dark and light modes of the same color configuration but only with different background colors and dimmer color plates.
And there was no solution to doing anything like that. Or anything that I was aware of. I developed a tool called themeX. In themeX you could define a color plate with different sets of colors. Lets say a dark theme and a light theme in which both defined the color variable blue. Then you could specify tokens of with the variable colors. When building themeX would build each plate into a different color and so your color themes could share the token definitions and only differ in the colors themselves.
The other capability of themeX was that it was a generic system. For each editor you would have developed an adaptor builder which builds the theme information for the target editor. I obviously started with implementing a tmTheme adapter and built the theme I wanted in the foundations of themeX. The theme that eventually became Kary Pro Colors.
I tried a lot at first to at least support the three big editors: Atom & Sublime Text and also the Visual Studio Code (which at the time I was betting on.)
The problem was only that each editor had its own different language definition of the same language. At first I thought of shipping tmLanguage files along with the theme so that it could support itself and after a while I decided that all tokens but the punctuation must be colored (and colored correctly). That became a very huge challenge since I now had to very carefully define every single token in the spec of that language's tmLanguage file.
Here I needed to decide if I want to develop a theme or also ship language definition for many different languages. Pro Colors also had suddenly been gaining popularity and I wanted to do a good job on it.
Before Visual Studio Code natively supported Workbench Color Customization, Me and a few other theme authors used to inject custom CSS to the system and theme the rest of the editor. To this day, Pro Colors is hosted in two different repositories. One contains the token core and one contains the spacial vscode-procolors.
This was so much for me. Keeping track of editions of Visual Studio Code and what should be added to the theme itself is enough for me to burn me out. Community feedback for adding more languages are never ending and so one man trying to keep a theme in all editors was something very hard for me. Now not only that but it became technically impossible too.
After the first year of releasing the theme, I was obsessed with making the definitions as accurate as possible. I wanted to have every token colored and I wanted to have the colors have harmony with each other. Something that I have never seen in other themes.
Given the power that tmTheme, tmLanguage and themeX had given me I could do just that. My involvement over the years raised from just authoring the theme to also authoring and contributing to many language definitions. I started with my own languages like Arendelle, KaryScript and Pageman. Then I developed language support for file formats like IDF, languages like Nearly and Racket, and contributing to many core languages like C#, Make, TypeScript, JavaScript, etc. And many third party languages like V and WebAssembly. This marked so much work in making the theme good for the languages and the languages good for the theme.
Currently Pro Colors has special tokens for 40 languages. Something that I don't think you will ever find anywhere in the industry and that is why I named the theme the Pro Colors.
Most of these languages are very carefully colored, something you cannot replicate in other editors. And that unfortunately is the sad truth about Pro Colors. In the past years I have tried a lot to port Pro Colors to different editors (I remember trying with Xcode, Coda, Nova, Pythonista) and all of them failed big time since their engines were so basic that they just couldn't handle something as big as Pro Colors.
I even tried to make a "Bare Minimum Dark" version of the theme but then I really didn't like the idea of dumbing down Pro Colors. If good editors come that actually let me port a good quality of Pro Colors to them, I will. But till then. I don't want to see a bad version of Pro Colors. And that is why I think my themeX project failed too.