-
Notifications
You must be signed in to change notification settings - Fork 321
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Colors #145
Conversation
As an FYI, I dislike several of these changes; having them show up unannounced was unwelcome. I went ahead and installed via git clone and reverted this PR to get the previous behavior back and I won't be maintaining parity with future dev, for what it's worth. It would be preferential for significant updates to these colors to be provided alongside the existing colorways. ST2/3 Package Control does not, unfortunately, allow locking to a major version, so typical semantic versioning isn't useful. |
Hey @coreyward. I thought this update would be welcome 🙁 Can you please point out what changes you don’t like in particular? |
Using Ruby: the “Library function” color highlights a bunch of insignificant methods in red, adding visual noise without providing additional information to me. I don’t need to see that ‘to_hash’ is implemented somewhere in Ruby core, for example. Also in Ruby: highlighting instance variables the same as method names breaks the visual hierarchy. I don’t really even like coloring ivars differently than local or block local vars, but if it’s going to happen it should be subtle and not conflict with the method name or constant highlights. I’m also not sold on coloring separators differently. |
You have a point @coreyward. Highlighting for ruby should be improved. Ruby is one of those languages which are hard to highlight properly, I’ll revisit issues you pointed out in next minor release. |
No description provided.