[vim/vim] Add Gruvbox colorscheme (#2573)

[Lifepillar]

In order to push forward #1665, I am submitting a variant of the popular Gruvbox colorscheme, which I believe is suitable for inclusion in Vim.

Gruvbox's author has shown no interest in shipping Gruvbox with Vim, so I have a created a simplified and optimized version. See https://github.com/lifepillar/vim-gruvbox8 for a summary of the differerences.

I have checked the colorscheme with check_colors.vim, with no issues.

---

You can view, comment on, or merge this pull request online at:

  https://github.com/vim/vim/pull/2573

Commit Summary

• Add Gruvbox 8 colorscheme.

File Changes

• A runtime/colors/gruvbox8.vim (756)
• A runtime/colors/gruvbox8_hard.vim (756)
• A runtime/colors/gruvbox8_soft.vim (756)
• A runtime/doc/gruvbox8.txt (63)

Patch Links:

• https://github.com/vim/vim/pull/2573.patch
• https://github.com/vim/vim/pull/2573.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub

[Wang Shidong]

User who like this colorscheme can use a plugin manager though.

[Bastian Venthur]

Sure you can always install external colorschemes but it also does not hurt vim to provide a sensible set of polished ones itself.

[Wang Shidong]

That base on the author's thought. there 1000+ colorschemes in github, will you add all of them into vim runtime? that will make vim even bigger.

[Wang Shidong]

and I just read the diff of this pr, it is really not same as gruvbox src, and hard to understand. gruvbox's code is well maintained.

[Bastian Venthur]

I wasn't advertising on accepting this specific colorschme but updating the ones we have and adding a few more. E.g. the ones shipping with vim have problems as the new test script confirms.

[Lifepillar]

it is really not same as gruvbox src, and hard to understand

I beg to disagree. Sure, it is completely rewritten, but easier to understand. It is easier to understand:

1. for users, because its options are documented—no need to browse the source code;
2. for developers, because it is generated from a high-level strutctured template with intuitive syntax (using my Colortemplate plugin);
3. for automatic tools (check_colors.vim), because it has the format such tools expect.

That said, if there is no consensus, maybe it's better to close this. I know that 2. is controversial (Vim developers understandably don't want to depend on external tools—although they do not maintain the runtime directly, AFAIK) and I certainly do not want to start a rush to getting dozens of new colorschemes into Vim.

I wrote gruvbox8 for myself mainly because the “official” gruvbox is bloated and messes up syntax highlighting after switching away from it. I thought that, given its popularity and #1665, I might try to get it into Vim. But I don't want to push this any further: after all, “who likes this colorscheme can use a plugin manager” :)

Perhaps, the best way to address #1665, apart from updating the existing colorschemes, would be a (community-driven?) effort to develop an original (and default?) colorscheme… Something with a distinct personality, to make people say “it's Vim!” just by looking at the colors :)

[Bram Moolenaar]

Let's not add individual color files, we need to select a set of distinct color schemes to include in the distribution. Unfortunately selecting those was never finished.

[Bram Moolenaar]

Closed #2573.

[Christian Brabandt]

so how should the community select a set of distinct color schemes? Shall we have a new survey and select the top 10 well-maintained color schemes?

[Bram Moolenaar]

> So how should the community select a set of distinct color schemes?

> Shall we have a new survey and select the top 10 well-maintained color
> schemes?

We should first define a few categories, such as "dark", "light",
"colorful", "subtle", etc. Then pick the best in each category.
Otherwise we end up with lots of dark schemes that are quite similar.
The distribution should not have more than a dozen or so, then users can
quickly find one they like.

--
A computer programmer is a device for turning requirements into
undocumented features. It runs on cola, pizza and Dilbert cartoons.
Bram Moolenaar

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Christian Brabandt]

So let's define a couple of categories and then we make a survey?

So let's use the categories:

• dark
• light
• colorful
• subtle(?)
• grayscale/monotone(?)

To be able to distribute it, the colorschemes must be maintained, include some documentation about the configuration and support terminal and gui colors in dark and light background color mode, right?

So we open a new issue and ask colorscheme developers who want their schemes to be distributed with Vim to show screenshots in dark and light mode and let users vote (for a month). If we take the best rated color scheme per category that would add 5 colorschemes to be included with Vim. We could always add new colorscheme categories (and colorschemes) later, if we missed something obvious.

Would that be a sensible way to move forward here?

[Bram Moolenaar]

Christian wrote:

> So let's define a couple of categories and then we make a survey?
>
> So let's use the categories:
>

> - dark
> - light
> - colorful
> - subtle(?)
> - grayscale/monotone(?)

>
> To be able to distribute it, the colorschemes must be maintained,
> include some documentation about the configuration and support
> terminal and gui colors in dark and light background color mode,
> right?
>
> So we open a new issue and ask colorscheme developers who want their
> schemes to be distributed with Vim to show screenshots in dark and
> light mode and let users vote (for a month). If we take the best rated
> color scheme per category that would add 5 colorschemes to be included
> with Vim. We could always add new colorscheme categories (and
> colorschemes) later, if we missed something obvious.
>
> Would that be a sensible way to move forward here?

It's a start. We can ask users to suggest other categories.

Some colorschemes set 'background' themselves, or expect always dark or
light. Others support both dark and light, we should probably judge
both then. It's almost like two colorschemes in one.

We also need to check what highlight groups are set properly. One way
is to source the $VIMRUNTIME/colors/tools/check_colors.vim script.
We may want to improve that script a bit further.

We would also need to check what terminals are supported. E.g. the good
old DOS console has limited color support, while we have full-color in
some terminals, but many only have 256 or even less.

It's not that every color scheme has to support all kinds of terminals,
but we do want a good choice of colorschemes also in a terminal with
only 16 colors.

--
`When any government, or any church for that matter, undertakes to say to
its subjects, "This you may not read, this you must not see, this you are
forbidden to know," the end result is tyranny and oppression no matter how
holy the motives' -- Robert A Heinlein, "If this goes on --"

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—

[Christian Brabandt]

Okay, I created #4996 in order to drive this forward. We don't have to discuss this here in this closed PR.

Thanks!