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.

[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.

[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).

[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.

[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".]

[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.

[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]

@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.

[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

[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)?

[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.

[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]

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.

[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).

[vitaly-zdanevich]

Please consider to include gotham, I use it for the last year.

I agree that out of the box themes looks badly.

[dngray]

We are looking at making a high quality theme for vim: selenized which includes 4 variants and improves upon some of the problems with solarized. You can read more about the features and design as well as the thought that went into it.

[wsdjeg]

Instead of merged this colorsheme into vim runtime, using independent github repo is better.

1, when there is some issue/bug with this colorscheme, we do not need to wait to vim-patch
2. to fix a issue/bug of colorscheme, we just need to update the plugin via :PlugUpdate etc. we do not need to udpate the vim package in os.

[chrisbra]

Well of course, but this is already possible. But there are 2 things to consider:

1. we would like to distribute vim with nice looking colorschemes, so that Vim out of the box looks nice (in the terminal and in the gui) and no one has to install git, vim-plug etc to install additional colorschemes (this is a problem for windows)
2. if you are using vim on a pc without an internet connection, you can't easily install colorschemes using packages/plugins, etc

[romainl]

So, @chrisbra, where are we on this topic and the related #4996? @lifepillar and I are both willing to organise a call for colorschemes in a separate repo but that repo should be part of this organisation. Can it be created? Can we be invited?

How can we help move this further?

[chrisbra]

okay, here we go: https://github.com/vim/colorschemes

[chrisbra]

You and @lifepillar got an invitation. You should be able to actively push code there. Once you feel like we have a good state of some example colorscheme, you can tag it and I would suggest @brammool to copy a snapshot over than.

I hope @brammool is okay with that.

[lifepillar]

@chrisbra Thanks for the invitation! For various reasons, however, I am not currently able to dedicate the required attention to this. So, as much as I would like to contribute, I am afraid I have to politely decline. But I am confident that @romainl and others that will join forces will do an excellent job and achieve great results!

[romainl]

That's too bad. Good luck for whatever you are doing, @lifepillar. Le mar. 5 mai 2020 à 22:33, Lifepillar <notifications@github.com> a écrit :

…

@chrisbra <https://github.com/chrisbra> Thanks for the invitation! For various reasons, however, I am not currently able to dedicate the required attention to this. So, as much as I would like to contribute, I am afraid I have to politely decline. But I am confident that @romainl <https://github.com/romainl> and others that will join forces will do an excellent job and achieve great results! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1665 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACUCD3E7ZEZX2QDFGWRUV3RQBZZVANCNFSM4DJPMCBQ> .

-- Romain Lafourcade