Sublime Forum

MonokaiFree color scheme

#1

A beautiful, professional, high quality, polished, free, Monokai color scheme for Sublime Text

Build Status Minimum Sublime Version Latest Stable Version GitHub stars Downloads Author

Many Monokai color schemes available for Sublime Text are not kept up to date, don’t support plugins, use too many variants of the same colors, or only exist to be compatible with a specific theme. They tend to go out of date and break in unexpected and unknown ways. ColorSchemeUnit, which is a testing framework for Sublime Text color schemes, helps improve the quality of color schemes and prevent regressions.

Available from Github and Package Control.

4 Likes

#2

Nice to see, someone concerns about modern features and latest developments in syntax highlighting.

Have two notes:

  1. You may have a look at https://github.com/sublimehq/Packages/issues/1036 to check out some default markup scopes which should be supported by current color schemes and syntaxes.
  2. As the color scheme contains the more general markup.ignored scopes, the more specific markup.ignored.git_gutter rules are not required.
0 Likes

#3

I agree with the proposal. I’ve actually got many of those proposed scopes already defined (future proofing). I added a bunch of generic scopes when I was adding support for GitGutter and SublimeLinter.

Source Control

gutter.scm.added
markup.inserted
markup.inserted.git_gutter
gutter.scm.changed
markup.changed
markup.changed.git_gutter
gutter.scm.deleted
markup.deleted
markup.deleted.git_gutter
gutter.scm.ignored
markup.ignored
markup.ignored.git_gutter
gutter.scm.untracked
markup.untracked
markup.untracked.git_gutter

Linters

message.error
gutter.linter.mark
linter.error
linter.warning
sublimelinter.gutter-mark
sublimelinter.mark.error
sublimelinter.mark.warning

Search

I use extra (backwards compat.) scopes for search highlighting in plugins like NeoVintageous:

string.search
string.search.occurrence

PR for Solarized: https://github.com/braver/Solarized/pull/58

Testing Tools

It would be nice to have some scopes for testing plugins like PHPUnitKit too. I haven’t got around to figuring out what these might be. The ones I currently use are a mess and I have to auto generate special color schemes on the fly: https://github.com/gerardroche/sublime-phpunit/blob/bf71b04b356b502c26877ad7cb3497ca20f7df2b/plugin.py#L408.

These scopes are slightly different that the gitgutter and linter scopes because in the test output you generally want background colours rather than foreground ones.

0 Likes

#4

Are there some examples where this scheme improves over the default one? I can only see some small differences in line numbers and css syntax.

0 Likes

#5

Can you tell me what plugin uses these scopes? Thanks :wink:

0 Likes

#6

There are bug fixes and subtle enhancements here and there. For the moment, mostly in the php syntax, because that’s where I work most. Up until now I’ve been using the php-grammar package which has a custom php syntax so it seems to work best in that, but with the new features in PHP even php-grammar is starting to break, so I’m currently in the process of getting rid of that custom syntax so that I can focus on polishing and fixing things better for the default syntax. It’s a too much work supporting two syntaxes anyways.

There’s also enhanced plugin support. Plugin authors, please open a ticket about adding support for your plugins.

Up until now, most of the work has been on ColorSchemeUnit, refining the color palette, and putting in place a robust test suite to help prevent regressions and make it easier to bug fix (and I still have to get shot of the custom syntax in php-grammar). Mostly preparation work.

One of the motivations for ColorSchemeUnit is that I found that anytime I tried to fix an issue with one syntax, if I used too generic a scope, oppose to a specific scope targeting that specific syntax, then syntax highlighting breaks in unknown ways, because it’s near impossible to manually test that you haven’t broken anything when you make general changes.

It also helps identify when changes to the underlying syntaxes change the syntax highlighting. Sometimes it’s for the better, but sometimes you need to make corrections. It’s also not just about identifying breakages, tests can help identify where enhancements can be made due to improvements in the underlying syntaxes e.g. when a syntax adds string interpolation scopes so that you can target constants and placeholders in strings.

So please open issues about syntax highlighting bugs (no matter how trivial). Also please don’t hesitate to open tickets about suggested enhancements and improvments. The test suite makes it fairly easy fix bugs and make changes without breaking things.

1 Like

#7

Those are old scopes way back from an attempt to formalise scopes for scm, linting, and the gutter. They can be safely ignored. @deathaxe’s approach of formalising the scopes in default syntaxes is better. I’ll be cleaning up those definitions as suggested by @deathaxe.

1 Like

#8

Is the current selection “inverted” style on purpose? I kinda like the original one better.

MonokaiFree

Monokai (default)

0 Likes

Dev Build 3148
#9

Yes that’s intentional. Ideally the fg and bg would invert like in vim:

I find there are some issues with the default e.g. any fg colors close to the selection bg are hard to see.

I’ll maybe revisit it later and refine it more.

0 Likes

#10

Is that possible in ST < 3148?

0 Likes

#11

No, that’s never been possible in ST, isn’t likely to happen either.

0 Likes

#12

No, the screenshot you’re referring to is from Vim.

Sadly, probably not.

0 Likes