New colorschemes

[0matgal0]

Please consider updating existing colorscheme / adding new ones.

Most of the colorschemes bundled with vim are gvim only or look bad in terminal.

Better colorschemes are a must.

[chrisbra]

Well, colorschemes are easy enough to find, e.g. vim-colorschemes That is not really a bug.

[chrisbra]

Well, colorschemes are easy enough to find, e.g. vim-colorschemes That is not really a bug.

[ZyX-I]

Availability of third-party colorschemes does not make bundled ones look good in terminal. It looks like bundled ones are staying with 4- or 3-bit colors while you can hardly find terminal emulator with does not support 8-bit colors. I would say it is a valid request to ship some good-looking default256 colorscheme used by default when terminal was detected to support 8-bit colors.

[ZyX-I]

Availability of third-party colorschemes does not make bundled ones look good in terminal. It looks like bundled ones are staying with 4- or 3-bit colors while you can hardly find terminal emulator with does not support 8-bit colors. I would say it is a valid request to ship some good-looking default256 colorscheme used by default when terminal was detected to support 8-bit colors.

[vim-ml]

On Fri, Apr 28, 2017 at 3:17 PM, Nikolai Aleksandrovich Pavlov ***@***.***> wrote: Availability of third-party colorschemes does not make bundled ones look good in terminal. It looks like bundled ones are staying with 4- or 3-bit colors while you can hardly find terminal emulator with does not support 8-bit colors. I would say it is a valid request to ship some good-looking default256 colorscheme used by default when terminal was detected to support 8-bit colors.

I would also chime in to suggest bundling of truecolor compatible schemes. If anyone is interested in doing this, pick your favorites and talk to the creator about possible bundling with Vim.

[vim-ml]

On Fri, Apr 28, 2017 at 3:17 PM, Nikolai Aleksandrovich Pavlov ***@***.***> wrote: Availability of third-party colorschemes does not make bundled ones look good in terminal. It looks like bundled ones are staying with 4- or 3-bit colors while you can hardly find terminal emulator with does not support 8-bit colors. I would say it is a valid request to ship some good-looking default256 colorscheme used by default when terminal was detected to support 8-bit colors.

I would also chime in to suggest bundling of truecolor compatible schemes. If anyone is interested in doing this, pick your favorites and talk to the creator about possible bundling with Vim.

[brammool]

I hardly ever get patches for color schemes, even though there are likely several that got outdated, they don't include definitions for highlight groups added later.
At the same time, removing a color scheme will always hurt those people who were using them anyway (and perhaps put their own fixes on top of it).
Thus best is if we can:

1. Make existing color schemes work well
2. Add a few color schemes that take advantage of terminals that support many colors.

[brammool]

I hardly ever get patches for color schemes, even though there are likely several that got outdated, they don't include definitions for highlight groups added later.
At the same time, removing a color scheme will always hurt those people who were using them anyway (and perhaps put their own fixes on top of it).
Thus best is if we can:

1. Make existing color schemes work well
2. Add a few color schemes that take advantage of terminals that support many colors.

[chrisbra]

So any suggestions what colorschemes should be bundled (provided that the license allows distribution with Vim)? Should look fine in the GUI and in the terminal (with truecolor and 256 colors).

[chrisbra]

So any suggestions what colorschemes should be bundled (provided that the license allows distribution with Vim)? Should look fine in the GUI and in the terminal (with truecolor and 256 colors).

[luchr]

So any suggestions what colorschemes should be bundled?

Solarized
see also vim-colors-solarized

[luchr]

So any suggestions what colorschemes should be bundled?

Solarized
see also vim-colors-solarized

[CaioBianchi]

If there's any colorscheme that should be bundled in, that would have to be Solarized.

[CaioBianchi]

If there's any colorscheme that should be bundled in, that would have to be Solarized.

[chrisbra]

however, that one hasn't been updated in years, so likely does not work with termguicolors

[chrisbra]

however, that one hasn't been updated in years, so likely does not work with termguicolors

[luchr]

I use it for both gvim and vim (in mate-terminal) with the following settings:

let g:solarized_visibility="low"
let g:solarized_termcolors=256
let g:solarized_contrast="high"

if has('gui_running')
   colorscheme solarized
else
   if exists("&tgc")
       set tgc | colorscheme solarized
   else
       colorscheme koehler
   endif
endif

[I use it also inside vim inside tmux with the additional tmux setting set-option -g terminal-overrides ",xterm:Tc".]

[luchr]

I use it for both gvim and vim (in mate-terminal) with the following settings:

let g:solarized_visibility="low"
let g:solarized_termcolors=256
let g:solarized_contrast="high"

if has('gui_running')
   colorscheme solarized
else
   if exists("&tgc")
       set tgc | colorscheme solarized
   else
       colorscheme koehler
   endif
endif

[I use it also inside vim inside tmux with the additional tmux setting set-option -g terminal-overrides ",xterm:Tc".]

[vim-ml]

On Sun, Apr 30, 2017 at 2:10 PM, Christian Brabandt ***@***.***> wrote: So any suggestions what colorschemes should be bundled (provided that the license allows distribution with Vim)? Should look fine in the GUI and in the terminal (with truecolor and 256 colors).

I was going to recommend solarized as it is the only popular one I know of. Unfortunately it would probably take someone with an artistic eye going through some of the color schemes, and that type of person seems to be rare in FOSS communities. Regardless of how many suggestions are brought up immediately, I think having this conversation on the list is helpful for future contributors. Something I forgot to bring up is that many terminals allow their own themeing that is not visible to applications run in them - does anyone know to what extent this is responsible for the poor look of the bundled themes?

[vim-ml]

On Sun, Apr 30, 2017 at 2:10 PM, Christian Brabandt ***@***.***> wrote: So any suggestions what colorschemes should be bundled (provided that the license allows distribution with Vim)? Should look fine in the GUI and in the terminal (with truecolor and 256 colors).

I was going to recommend solarized as it is the only popular one I know of. Unfortunately it would probably take someone with an artistic eye going through some of the color schemes, and that type of person seems to be rare in FOSS communities. Regardless of how many suggestions are brought up immediately, I think having this conversation on the list is helpful for future contributors. Something I forgot to bring up is that many terminals allow their own themeing that is not visible to applications run in them - does anyone know to what extent this is responsible for the poor look of the bundled themes?

[lifepillar]

So any suggestions what colorschemes should be bundled (provided that the license allows distribution with Vim)? Should look fine in the GUI and in the terminal (with truecolor and 256 colors).

Above all, gruvbox. But also:

• seoul256;
• Lucario;
• Pencil;
• PaperColor;
• Alduin;
• Base2Tone;
• Jellybeans.
• Tomorrow.

They all support true colors, and their 256-color approximations look reasonably good (I haven't checked their licenses).

I maintain a version of Solarized that supports true colors (called Solarized8), but I have dropped the 256-color variant of the original Solarized because it just looked… wrong.

[lifepillar]

So any suggestions what colorschemes should be bundled (provided that the license allows distribution with Vim)? Should look fine in the GUI and in the terminal (with truecolor and 256 colors).

Above all, gruvbox. But also:

• seoul256;
• Lucario;
• Pencil;
• PaperColor;
• Alduin;
• Base2Tone;
• Jellybeans.
• Tomorrow.

They all support true colors, and their 256-color approximations look reasonably good (I haven't checked their licenses).

I maintain a version of Solarized that supports true colors (called Solarized8), but I have dropped the 256-color variant of the original Solarized because it just looked… wrong.

[chrisbra]

I would also like to see vim-molokai (unfortunately, does not seem to support termguicolors, vim-monokai (does not support 16 colors, not sure about termguicolors) and vim-janah (does not support 16 colors, but supports termguicolors) and perhaps base16-default. At least those were the ones besides gruvbox, that I have enjoyed to use in the past.

[chrisbra]

I would also like to see vim-molokai (unfortunately, does not seem to support termguicolors, vim-monokai (does not support 16 colors, not sure about termguicolors) and vim-janah (does not support 16 colors, but supports termguicolors) and perhaps base16-default. At least those were the ones besides gruvbox, that I have enjoyed to use in the past.

[chrisbra]

okay, asked authors for there permissions.

[chrisbra]

okay, asked authors for there permissions.

[chrisbra]

@brammool I already got some responses back. You will probably be send a couple of colorschemes by either me or their original authors. (sorry for spamming)

[chrisbra]

@brammool I already got some responses back. You will probably be send a couple of colorschemes by either me or their original authors. (sorry for spamming)

[jsit]

I'd like to humbly suggest my theme, disco.vim, which uses the colors in one's terminal settings but has definitions for many more keywords than most similar themes.

[jsit]

I'd like to humbly suggest my theme, disco.vim, which uses the colors in one's terminal settings but has definitions for many more keywords than most similar themes.

[vyp]

I would really like @jsit's disco.vim to be bundled because I think it would be really useful to have a bundled theme that uses one's terminal colors. :) ✌️

@jsit I'm assuming you are okay with releasing it under the same license as vim in that case? (At the moment I don't see any license.)

[vyp]

I would really like @jsit's disco.vim to be bundled because I think it would be really useful to have a bundled theme that uses one's terminal colors. :) ✌️

@jsit I'm assuming you are okay with releasing it under the same license as vim in that case? (At the moment I don't see any license.)

[jsit]

@vyp Added Vim license to disco.vim readme

[jsit]

@vyp Added Vim license to disco.vim readme

[romainl]

This is all well and good but too many of the modern colorschemes listed here and on the related r/vim thread are either poorly written or over-engineered or both. And they tend to need exhaustive documentation to describe their many options, system requirements and caveats. A documentation no one ever reads or understands anyway.

Solarized and Gruvbox are the worst offenders with their myriad of badly documented options and their anti-hacking design and the worst part is that so many others seem to follow the same patterns.

Adding fancy.vim to colors/ won't be enough. Each colorscheme has to come with a proper fancy.txt so that smart users can read all about the available options and less smart ones can keep skipping the doc and flood Vim's issue tracker with colorscheme-related complains.

[romainl]

This is all well and good but too many of the modern colorschemes listed here and on the related r/vim thread are either poorly written or over-engineered or both. And they tend to need exhaustive documentation to describe their many options, system requirements and caveats. A documentation no one ever reads or understands anyway.

Solarized and Gruvbox are the worst offenders with their myriad of badly documented options and their anti-hacking design and the worst part is that so many others seem to follow the same patterns.

Adding fancy.vim to colors/ won't be enough. Each colorscheme has to come with a proper fancy.txt so that smart users can read all about the available options and less smart ones can keep skipping the doc and flood Vim's issue tracker with colorscheme-related complains.

[jsit]

I agree with @romainl, which is why I strive to make disco.vim as bullet-proof as possible.

[jsit]

I agree with @romainl, which is why I strive to make disco.vim as bullet-proof as possible.

[romainl]

To follow up my previous comment, I looked at all the colorschemes where @chrisbra opened an issue. Here is the result:

Colorscheme	Needs an help file	Has an help file	Ready for inclusion
alduin	YES	NO	NO
apprentice	NO	NO	YES
badwolf	YES	NO	NO
base2tone	NO	NO	YES
disco	NO	NO	YES
dracula	NO	NO	YES
gruvbox	YES	NO	NO
janah	NO	NO	YES
jellybeans	YES	NO	NO
lucario	NO	NO	YES
molokai	YES	NO	NO
monokai	YES	NO	NO
papercolor	YES	NO	NO
pencil	YES	NO	NO
seoul256	YES	NO	NO
tomorrow	NO	NO	YES

[romainl]

To follow up my previous comment, I looked at all the colorschemes where @chrisbra opened an issue. Here is the result:

Colorscheme	Needs an help file	Has an help file	Ready for inclusion
alduin	YES	NO	NO
apprentice	NO	NO	YES
badwolf	YES	NO	NO
base2tone	NO	NO	YES
disco	NO	NO	YES
dracula	NO	NO	YES
gruvbox	YES	NO	NO
janah	NO	NO	YES
jellybeans	YES	NO	NO
lucario	NO	NO	YES
molokai	YES	NO	NO
monokai	YES	NO	NO
papercolor	YES	NO	NO
pencil	YES	NO	NO
seoul256	YES	NO	NO
tomorrow	NO	NO	YES

[cocopon]

Hello, I'm a developer of colorscheme gallery for Vim: colorswat.ch.
I suggested these colorschemes that aren't contained the list:

• Nord (see #1665 (comment))
• Iceberg (my one)
• hybrid

Because they are...

• high quality coloration
• well-maintained
• supported 256-colors (ctermbg/fg)
• easy to use (looks good without any options)

[cocopon]

Hello, I'm a developer of colorscheme gallery for Vim: colorswat.ch.
I suggested these colorschemes that aren't contained the list:

• Nord (see #1665 (comment))
• Iceberg (my one)
• hybrid

Because they are...

• high quality coloration
• well-maintained
• supported 256-colors (ctermbg/fg)
• easy to use (looks good without any options)

[jsit]

@cocopon: "Nord Vim in terminal mode MUST be used with the associated terminal emulator theme in order to work properly!" This doesn't sound user-friendly to me at all. I think any colorscheme included with Vim would need to work out-of-the-box.

[jsit]

@cocopon: "Nord Vim in terminal mode MUST be used with the associated terminal emulator theme in order to work properly!" This doesn't sound user-friendly to me at all. I think any colorscheme included with Vim would need to work out-of-the-box.

[cocopon]

@jsit Ah, you're right and I agree with you. I edited my list, thank you for the advice.

[cocopon]

@jsit Ah, you're right and I agree with you. I edited my list, thank you for the advice.

[xero]

as a maker of vim color schemes, i'd be beyond honored if you considered including sourcerer {and,or} blaquemagick.

but i think noctu is a great choice, since it's designed to use the user's local 16 colors only. it's great for people who want vim to change appearance with their xresources file.

[xero]

as a maker of vim color schemes, i'd be beyond honored if you considered including sourcerer {and,or} blaquemagick.

but i think noctu is a great choice, since it's designed to use the user's local 16 colors only. it's great for people who want vim to change appearance with their xresources file.

[romainl]

How many sorcerer derivatives do we need? ;-)

[romainl]

How many sorcerer derivatives do we need? ;-)

[lifepillar]

I have a proposal. Why not use (or even include in Vim) a color scheme generator to guarantee that color schemes distributed with Vim have a consistent structure and provide all the default highlight groups? For example, I have prepared this (*): https://github.com/lifepillar/vim-colorscheme-template, taking into account the comments in this thread, especially @romainl's.

A template would reduce the effort to create a color scheme (for example, I have created a version of Gruvbox dark in the example folder), it would restrain people from over-engineering (as long as they follow the instructions), and it would allow hacking the color scheme (by "recompiling" it from the template).

(*) I have baked it quickly, just as a proof of concept.

[lifepillar]

I have a proposal. Why not use (or even include in Vim) a color scheme generator to guarantee that color schemes distributed with Vim have a consistent structure and provide all the default highlight groups? For example, I have prepared this (*): https://github.com/lifepillar/vim-colorscheme-template, taking into account the comments in this thread, especially @romainl's.

A template would reduce the effort to create a color scheme (for example, I have created a version of Gruvbox dark in the example folder), it would restrain people from over-engineering (as long as they follow the instructions), and it would allow hacking the color scheme (by "recompiling" it from the template).

(*) I have baked it quickly, just as a proof of concept.

[chrisbra]

that looks promising. Could you also write some documentation on best practices, in vim doc format, that we could put into the distributed documentation? Perhaps at usr_41.txt (add a new section `Write a colorscheme plugin)?

[chrisbra]

that looks promising. Could you also write some documentation on best practices, in vim doc format, that we could put into the distributed documentation? Perhaps at usr_41.txt (add a new section `Write a colorscheme plugin)?

[tonymec]

«Providing all the default highlight groups» is not really a requirement: anything you don't set will remain as it was, or (depending if your colorscheme clears everything) in the vim-default colors.

I have created for my own use a colorscheme called "almost-default" whose :highlight lines concern only the highlight groups "forgotten" by the Vim defaults and those whose default I don't like. (It has :hi clear near the top so that anything the colorscheme doesn't mention remains at the Vim default.) An October 2009 version of it is at http://users.skynet.be/antoine.mechelynck/vim/almost-default.vim — it was originally meant only for my own use, but if you like it, you're welcome; conversely, if you don't like it, don't use it. ;-)

[tonymec]

«Providing all the default highlight groups» is not really a requirement: anything you don't set will remain as it was, or (depending if your colorscheme clears everything) in the vim-default colors.

I have created for my own use a colorscheme called "almost-default" whose :highlight lines concern only the highlight groups "forgotten" by the Vim defaults and those whose default I don't like. (It has :hi clear near the top so that anything the colorscheme doesn't mention remains at the Vim default.) An October 2009 version of it is at http://users.skynet.be/antoine.mechelynck/vim/almost-default.vim — it was originally meant only for my own use, but if you like it, you're welcome; conversely, if you don't like it, don't use it. ;-)

[romainl]

FWIW I, too, have a colorscheme template over there.

[romainl]

FWIW I, too, have a colorscheme template over there.

[lifepillar]

I have turned my experiment into an ftplugin. Now, you may edit a text-only template (with syntax coloring!) then type :Colortemplate and you have the colorscheme. I have freely stol… borrowed text and ideas from @romainl. Here it is: https://github.com/lifepillar/vim-colortemplate.

Could you also write some documentation on best practices, in vim doc format, that we could put into the distributed documentation? Perhaps at usr_41.txt (add a new section `Write a colorscheme plugin)?

I'll try to do that (possibly during the weekend). For now, there is some preliminary documentation in the plugin.

[lifepillar]

I have turned my experiment into an ftplugin. Now, you may edit a text-only template (with syntax coloring!) then type :Colortemplate and you have the colorscheme. I have freely stol… borrowed text and ideas from @romainl. Here it is: https://github.com/lifepillar/vim-colortemplate.

Could you also write some documentation on best practices, in vim doc format, that we could put into the distributed documentation? Perhaps at usr_41.txt (add a new section `Write a colorscheme plugin)?

I'll try to do that (possibly during the weekend). For now, there is some preliminary documentation in the plugin.

[lifepillar]

I have updated my colortemplate plugin (https://github.com/lifepillar/vim-colortemplate). Apart from bug fixes, lots of more or less minor tweaks and slightly better documentation, these are some relevant new features:

• templates for colorschemes with both dark and light variants are supported (see examples/templates/gruvbox.txt);
• parsing errors and some bad practices (e.g., Normal groups not defined at the top) are detected and added to a location list automatically displayed to the user;
• it is possible to insert verbatim code;
• the generated colorscheme may be saved at once: just pass a path to :Colortemplate.

Start with :help ft-colortemplate.

As a proof of concept, I have included a complete version of Gruvbox (Gruvbox's author has shown no interest in maintaining a version in Vim distribution, AFAIK) and a “templatised” version of Pablo. The latter is to show how legacy colorschemes may be prepared to “make them work well” in the future (as suggested by @brammool).

To be clear, although I plan to maintain my plugin I do not plan to take over the development of any colorscheme (the only exception might be Solarized: I'm thinking to port my Solarized8 fork to the colortemplate format).

RE documenting best practices: I have seen that hints on writing colorschemes are located at $VIMRUNTIME/colors/README.txt. Unless you plan to move that content inside Vim manual, I think that a reference to colortemplate's documentation in the README itself would be enough. After all, if you use (and not abuse) a template, the resulting colorscheme is “ok by design”.

Feedback is welcome. I am curious, in particular, what you think about the colortemplate format and whether the derived colorschemes are missing anything.

[lifepillar]

I have updated my colortemplate plugin (https://github.com/lifepillar/vim-colortemplate). Apart from bug fixes, lots of more or less minor tweaks and slightly better documentation, these are some relevant new features:

• templates for colorschemes with both dark and light variants are supported (see examples/templates/gruvbox.txt);
• parsing errors and some bad practices (e.g., Normal groups not defined at the top) are detected and added to a location list automatically displayed to the user;
• it is possible to insert verbatim code;
• the generated colorscheme may be saved at once: just pass a path to :Colortemplate.

Start with :help ft-colortemplate.

As a proof of concept, I have included a complete version of Gruvbox (Gruvbox's author has shown no interest in maintaining a version in Vim distribution, AFAIK) and a “templatised” version of Pablo. The latter is to show how legacy colorschemes may be prepared to “make them work well” in the future (as suggested by @brammool).

To be clear, although I plan to maintain my plugin I do not plan to take over the development of any colorscheme (the only exception might be Solarized: I'm thinking to port my Solarized8 fork to the colortemplate format).

RE documenting best practices: I have seen that hints on writing colorschemes are located at $VIMRUNTIME/colors/README.txt. Unless you plan to move that content inside Vim manual, I think that a reference to colortemplate's documentation in the README itself would be enough. After all, if you use (and not abuse) a template, the resulting colorscheme is “ok by design”.

Feedback is welcome. I am curious, in particular, what you think about the colortemplate format and whether the derived colorschemes are missing anything.

[lifepillar]

My Colortemplate plugin has reached v1.0. Some highlights:

• it is possible to specify only GUI colors and have Colortemplate compute the best base-256 color approximations (and manually override some or all of Colortemplate's choices);
• it is possible to generate a colorscheme that supports both the 16 ANSI colors and xterm's 256 colors (besides GUI colors, of course);
• it is possible to document the colorscheme's options directly in the template and have a help file generated automatically.

The latter feature, in particular, should help address the issue of badly documented colorschemes (see @romainl's comment).

Creating templates is easy, and I have done it for that beast of a colorscheme that is Solarized, since there have been several requests for a Solarized theme in Vim. My Solarized8 fork (https://github.com/lifepillar/vim-solarized8) now includes both documentation and support for 256 color terminals, so it should satisfy the previously discussed requirements.

I hope this will help making progress on this issue!

[lifepillar]

My Colortemplate plugin has reached v1.0. Some highlights:

• it is possible to specify only GUI colors and have Colortemplate compute the best base-256 color approximations (and manually override some or all of Colortemplate's choices);
• it is possible to generate a colorscheme that supports both the 16 ANSI colors and xterm's 256 colors (besides GUI colors, of course);
• it is possible to document the colorscheme's options directly in the template and have a help file generated automatically.

The latter feature, in particular, should help address the issue of badly documented colorschemes (see @romainl's comment).

Creating templates is easy, and I have done it for that beast of a colorscheme that is Solarized, since there have been several requests for a Solarized theme in Vim. My Solarized8 fork (https://github.com/lifepillar/vim-solarized8) now includes both documentation and support for 256 color terminals, so it should satisfy the previously discussed requirements.

I hope this will help making progress on this issue!

[venthur]

If you bundle new colors with vim, please make sure to support termguicolors. Solarized for example does not support it but it can be easily fixed.

[venthur]

If you bundle new colors with vim, please make sure to support termguicolors. Solarized for example does not support it but it can be easily fixed.

[lifepillar]

Thus best is if we can:

Make existing color schemes work well

As a proof of concept, I have taken the pablo colorscheme and I have “modernized” it. Which means:

1. add support for a 256 color palette (pablo uses only GUI and ANSI colors), but still support 16 colors (triggered by an option);
2. add all missing highlight groups, with default definitions;
3. set all highlight group attributes;
4. define an option to set an opaque or transparent background (pablo does not set the background for Normal);
5. document the (two) options.

Other than that, the colorscheme should look the same as the current one. Code is here.

Is that what you mean by making the current colorschemes “work well”? It shouldn't be too difficult to do the same with the other colorschemes, but I am wondering whether it is worth the effort (also, I am not going to maintain the new code).

[lifepillar]

Thus best is if we can:

Make existing color schemes work well

As a proof of concept, I have taken the pablo colorscheme and I have “modernized” it. Which means:

1. add support for a 256 color palette (pablo uses only GUI and ANSI colors), but still support 16 colors (triggered by an option);
2. add all missing highlight groups, with default definitions;
3. set all highlight group attributes;
4. define an option to set an opaque or transparent background (pablo does not set the background for Normal);
5. document the (two) options.

Other than that, the colorscheme should look the same as the current one. Code is here.

Is that what you mean by making the current colorschemes “work well”? It shouldn't be too difficult to do the same with the other colorschemes, but I am wondering whether it is worth the effort (also, I am not going to maintain the new code).