expose variables for custom coloring

[JeanMertz]

This is both a question and a feature request.

The question is: what's the correct way to use gruvbox-defined colours when manually tweaking highlights for external vim plugins? Right now I'm just copying the colour hex values straight from the gruvbox source code, but is that the correct way?

If it is, would it be an option to publicly expose the variables containing the colours? so it's a) easier to use these colours, and b) makes it forward compatible with any changes in the palette.

[JeanMertz]

Or would the way forward be to extend the already existing list of highlight groups to include all acceptable colours?

[rbong]

The probablem with externally exposing colors is that they have to be defined all the time - otherwise they won't be defined unless the colorscheme is set to gruvbox. This will make anything that uses the colors fail if the colorscheme is something else, which is arguably fine, but it will also introduce load-order problems.

I can move these colors to a place that can be accessed at all times, but that adds an extra layer of redirection to already complex color definition system, and it won't fix all of the load order issues, since settings always need to go first so that the correct colors are always returned.

The way it's normally done is to follow the palette images in the readme. Also, if you submit your extension to gruvbox-contrib I can more easily update you with any changes to the palette (which are unlikely but have happened) and any other color developments.

I know it's not a perfect solution. Gruvbox is a big colorscheme with lots of different options and it can be hard to get right and it would be nice to just use the colors directly. I am leaving this issue open, because I do think it is a problem, I just wouldn't feel comfortable adding more complexity unless if there was huge support for this issue. I'm hoping there's just a better solution.