What did we learn so far?
romainl opened this issue · 10 comments
Now that we have shipped the remakes it is time for the next step: define the guidelines/best practices to enforce when considering the inclusion of new colorschemes.
To ease that process I thought it would be useful to grab a box of Lego, some markers and Post-it no jot down what we have learned about so far about user expectations, technical restrictions, etc. And maybe even suggestions for how to move forward.
If that can help, and although you probably already know about it, you may take a look at :help colortemplate-best-practices. Maybe, the kind of guidelines you have in mind are a bit more high-level than what is suggested there, but still there may be something interesting to consider.
And FYI, I still have a plan to release a v3 of Colortemplate eventually, rebuilt from scratch and simplified in many respects. You have used the templates a lot: if you have suggestions about improving the syntax, the semantics or the workflow, I'd like to hear your feedback. In fact, I do not plan to strictly preserve backward compatibility (Colortemplate v2 is stable and will still be around for the time being), so designing a somewhat different syntax is not out of question. I might even decide to go for a new (shorter!) name for the plugin.
-
No settings, e.g. if anyone needs to have italic comments -- let them use Colorscheme autocommand.
-
Support GUI, 256, 16, 8 colors (+ no colors with
_tcozero). In general it should be readable there. -
Use color names for 16 and 8 colors
-
Do not assume terminal has black background (define
Normalcolors) -
Typefaces should be used with caution (unless you are ok if in some cases your colorscheme becomes "minimal")
-
No dual background colorschemes
And it would be really nice to have a template for colortemplate (which we should have in the beginning :) ) to have not only uniformed colorschemes but also templates.
I agree, providing a template with lots of comments, a bit like RNB, would be great for bootstrapping new projects.
Or maybe that's something that should be part of Colortemplate?
Or maybe that's something that should be part of Colortemplate?
I guess it belongs to this repo, not to colortemplate (colortemplate allows many fancy things and I don't think it would be wise to soft-lock users to what we want to have in vim/colorschemes land)
Do not assume terminal has black background (define
Normalcolors)
To add to this: Normal should be defined first. That should be suggested somewhere in Vim's help. It would be nice if the other highlight groups were sorted lexicographically.
No dual background colorschemes
Why? I think that is supported by Vim.
a template with lots of comments, a bit like RNB, would be great for bootstrapping new projects.
Bootstrapping can be done from an existing color scheme with colortemplate#import#run(). If you need a “meta-template”, you may start with those provided by Colortemplate in its templates directory.
No dual background colorschemes
Why? I think that is supported by Vim.
Harder to support by us if author would decide to not to.
- Do not assume terminal has black background (define
Normalcolors)
I'd reword that as "Always be explicit," two of the bugs I've reported now have been because something that could be set like Terminal in the latest one, was left cleared , and the first one with TabLine was the same. Don't trust any "fallthrough" behaviour because there's so many variations underneath.
No dual background colorschemes
Why? I think that is supported by Vim.
Harder to support by us if author would decide to not to.
I take it back
Other guideline/best practice (or, even better, something to be enforced) for future color schemes: set minimum threshold for acceptable contrast, at least for main fg/bg colors (Normal). Unless low-contrast color schemes are considered acceptable, of course.
I would also encourage/enforce people to limit the color difference between the GUI and (xterm) terminal values (the “delta” value provided by Colortemplate's color similarity table) to some realistic upper bound. This is more delicate, because the xterm palette is very limited, but it would be an objective argument to reject color schemes such as Solarized, whose 256-color version is… well, another color scheme entirely (which surprises many users).
And talking about Solarized: I would also encourage (or, in this case, I'm very keen to say: enforce) that the terminal colors (g:terminal_ansi_colors) be set to “sensible colors”, i.e., color 1 should look reddish, color 2 should look greenish, and so on). There is currently no statistics in Colortemplate to measure how “sensible” terminal colors are, but it could be added, e.g., as a color difference between a color scheme's terminal color and a default (xterm) value.
A problem with these rules is that they are easy to check if the color scheme is done with Colortemplate, but they may difficult to check otherwise. A possible solution might be to move all the color-related functions to an independent (and community-maintained) plugin. Someone could also add some functions to measure various blind-color issues—something I had wanted to do for a while, but I haven't had time to do yet. Thoughts?