Export color and format variables in a global dictionary #32

Open
wants to merge 1 commit into
from

Conversation

Projects
None yet
4 participants

drslump commented Sep 18, 2011

To be able to use the final values obtained by the solarized color scheme in user customizations, the local variables fg_xxx, bg_xxx and fmt_xxx are exported in a new global variable of type dictionary called g:solarized_vars. So they can be accessed easily following the syntax g:solarized_vars.fg_base0.

@drslump drslump Export color and formatting variables in a global dictionary
To be able to use the final values obtained by the solarized color
scheme in user customizations, the local variables fg_xxx, bg_xxx and
fmt_xxx are exported in a new global variable of type dictionary
called g:solarized_vars. So they can be accessed easily following the
syntax g:solarized_vars.fg_base0.
18375fa

Exactly what I was looking for; thanks. Now I can make myself a customized solarized statusline.

cdlm replied Feb 29, 2012

Ping?

cdlm referenced this pull request Feb 29, 2012

Open

Merge a few simple pullreqs #39

blaenk commented Feb 5, 2017

This would seriously be very useful especially for allowing users to use Solarized variables for highlight groups like User1 et al.

This theme does different checks to come to the final color values (gui running, light or dark background, color degradation, italics supported, etc.) which is why it's not correct to hard-code the color values in a user's own configuration.

The only alternatives are to either edit the solarized theme file itself or to paste the color value computation code into one's own configuration in order to use the "correct" colors, which is unnecessary when these values can simply be exported as this PR does.

Here's an example of what one currently has to do. Notice I basically pasted in the color computation code all so that I can (at the bottom of the diff) customize the User1, User2, etc. highlight groups. Those are about ~330 lines I could shave off if this PR were merged, not to mention that it's fragile to replicate it there in case Solarized's way of computing the colors ever changes.

For comparison, I added similar functionality to a Solarized theme for Emacs which enables users to tweak highlighting definitions or even add highlighting to things that aren't in the official theme and are unlikely to make it in. My point being that this is a very useful and indeed even expected piece of functionality. It allows the theme to serve as a foundation for the user's own customization.

In short, this PR seems like a very minor addition to the code in return for a verifiably large impact in usefulness for users. Despite being over 6 years old it still has no conflicts. I don't see it being controversial, nor is it backwards incompatible. Therefore I strongly advise the maintainers (not sure who that is, @altercation ? @tpope ?) to consider merging this. Perhaps it went under their radar at first.

blaenk commented Feb 5, 2017

By the way, I think PRs are only considered when they're submitted to the main repository, which probably explains why no PRs made here have ever been merged.

It'd be great if you could resubmit this there @drslump, but if not then I can take a shot at it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment