feature/colormanager

[Consolatis]

Not to merge right away, just a request for comments.

The idea of the color manager is to never use raw curses color_pairs outside the manger itself but instead use config defined strings for color pairs.
Those can then be configured differently for 8, 88 or 256 colors.
defaults.json implements a basic set which can be modified individually by the user inside ~/.config/suplemon/suplemon-config.json.
A fallback to color_pair(0) is provided if Suplemon is running on a terminal without any kind of color support (e.g. vt220) or if the amount of color pairs requested is bigger than what the terminal provides.

The default config for 8 colors looks like this:

"colors_8": {
    "status_top":             { "fg": "white",   "bg": "black"   },
    "status_bottom":          { "fg": "white",   "bg": "black"   },
    "legend":                 { "fg": "white",   "bg": "black"   },
    "linenumbers":            { "fg": "white",   "bg": "black"   },
    "linenumbers_lint_error": { "fg": "red",     "bg": "black"   },
    "editor":                 { "fg": "default", "bg": "default" },
    "editor_whitespace":      { "fg": "black",   "bg": "default", "attribs": [ "bold" ] }
}

And the one for 256 colors like this:

"colors_256": {
    "status_top":             { "fg": "color250", "bg": "black"   },
    "status_bottom":          { "fg": "color250", "bg": "black"   },
    "legend":                 { "fg": "color250", "bg": "black"   },
    "linenumbers":            { "fg": "color240", "bg": "black"   },
    "linenumbers_lint_error": { "fg": "color204", "bg": "black"   },
    "editor":                 { "fg": "default",  "bg": "default" },
    "editor_whitespace":      { "fg": "color240", "bg": "default" }
}

The parser supports everything curses.COLOR_* and curses.A_* provides + direct integers in form of colo(u)r212 + the value "default" (terminal configured default values, e.g. semi-transparent or image backgrounds).

One of the open questions is if it is useful to use the hex2term color conversion to also allow hexencoded 24bit colors.
I did not implement that right away because it would also need to make sure that every combination has enough contrast, e.g. fg != bg or contrast(fg, bg) > x and I am generally not sure if it is a useful feature to have.

Syntax highlighting (pygments and linelight) creates new color pairs on demand / reuses previously created color pairs by reusing the integer which is currently used for the curses.color_pair as identifier for the color manager.

As this branch requires PRs #216 and #217 I based it on a local dev-next branch but will rebase it once they are merged into dev.

My current work for statusbar components is based on this branch because it allows to have a way more flexible color management, e.g. the user is able to define something like

{
    "filelist_active":        { "fg": "white",    "bg": "black"   },
    "filelist_other":         { "fg": "color240", "bg": "black"   },
    "lintlogo_warn":          { "fg": "color204", "bg": "black"   }
}

Things to do:

• maybe move config loading from ui.py into color_pairs.py (or config.py?)
• maybe move the whole setup_color() def to color_pairs.py
• bind to config event, update existing color pairs based on new config
• convert basically all info logging to debug
• color_pairs.py: use white for self._invalid if available colors < 8
• ui.py + defaults.json: add bkgdset() for legend window
• ui.py: maybe completely remove self.limited_colors
• viewer.py: for linelight return default editor fg instead of 0 (black) if nothing matches
• solve the last FIXMEs and TODOs
• define a final default design for 8, 88 and 256 colors (help required)
• rebase on dev
• squash

[richrd]

One of the open questions is if it is useful to use the hex2term color conversion to also allow hexencoded 24bit colors.

I'm not entirely sure what you mean by this. Are you asking whether colors such as #000000 should be supported?

[Consolatis]

I'm not entirely sure what you mean by this. Are you asking whether colors such as #000000 should be supported?

Yes that is what I meant. I tend to answer "no" to that question though, as I don't think it is worth the effort to get a solid implementation for the little benefit of using #333333 instead of color252.

[richrd]

Yeah, I think it's not necessary. Maybe one day but right now we don't need it.

[Consolatis]

Apart from defining the default color designs for 8, 88 and 256 colors and squashing into 2 commits this PR should be ready to merge from my POV.

Logging on a usual setup should be invisible on loglevel info and above other than for this startup message:

2018-03-08 09:24:07,285 - suplemon.color_manager_curses.ColorManager - INFO - Currently running with TERM 'tmux-256color' which provides 256 colors and 256 color pairs according to ncurses.

I figured it might be useful for users to always see it, although I can definitely lower it to debug instead.
There is another warning level message if running with anything < 256 colors including a hint that $TERM-256color may help so the startup message is not necessarily required to improve the user experience.

[richrd]

Sorry that this PR has been without comment for so long. I think I'm ready to merge this.

[Consolatis]

@richrd I accidentally rebased this branch on top of master, realized my mistake and rebased again on dev but master and dev diverged so this PR now contains some commits from master which are not available in dev. For the time being i'll leave it at that until dev is rebased on master (or master is merged into dev). git rebase -i origin/dev came to the rescue.

If you don't want to merge this and the statusbar PR feel free to close them and I keep it somewhere local instead.
In case you are still interested I'll squash this PR so it can be merged and doesn't clutter the history with "[WIP]" and "fixup" commits.