Standard git-color theme ui-variables


#1

Right now, I count three color-sensitive places that are aware of git statuses: the tree view, the gutter, and the status bar.

Each of these uses .git-added, .git-modified, and .git-removed classes. Right now I harness that with some rules in my style.less to use the same custom colors, matching my Twilight theme:

These seem common cross-cutting theme colors, that ought to gel well with whatever color scheme designers are using, so maybe they merits a place in ui-variables.less? I’m using @git-added-color, @git-modified-color, and @git-removed-color. Then the tree view, git gutter, and status bar projects could make use of them in tandem, and theme designers would have easy customization of git colors at their fingertips.


[Suggestion] Smarter new user restrictions
#2

If you pop open the style guide inside of Atom you can see there are some Git related classes already defined e.g. ‘status-ignored’, ‘status-modified’ etc. These are the classes that the tree-view and status-bar use.

I’ve also been successfully using them in my own package when dealing with Git statuses.


#3

Indeed! I’m more suggesting that since they’re present in many components, and have a common class and nomenclature already, they might merit first-class presence as ‘expected variables’ in themes. Namely, adding them to the expected ui-variables of a theme so that theme designers can easily style all of these many disparate .git-statusifed classes in one swell foop.


#4

Gotcha.

I know the ‘status-*’ classes are at least defined in the ui-variables for both of the built in UI themes. I agree with you. They should be standardised. Perhaps they should be these ‘status-*’ classes since they are already in use?


#5

Reviewing my styles.less posted above, it looks like they’re at least fragmented between status-* and git-line-*, but the status- form is more dominant from what I’ve seen. I’d personally favor a fully-qualified git-status-*, allowing for, say, other version control systems (likely, right github? ;)) and other git meta-data. But at the end of the day I’m pretty ambivalent as long as people agree it merits standardization and documentation.