[vim/vim] New colorschemes (#1665)

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

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

[Christian Brabandt]

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

[Nikolai Aleksandrovich Pavlov]

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.

[R0b0t1]

On Fri, Apr 28, 2017 at 3:17 PM, Nikolai Aleksandrovich Pavlov
<vim-dev...@256bit.org> 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-dev ML]

[Bram Moolenaar]

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.

—
You are receiving this because you commented.

[Christian Brabandt]

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

—
You are receiving this because you commented.

[luchr]

So any suggestions what colorschemes should be bundled?

Solarized
see also vim-colors-solarized

—
You are receiving this because you commented.

[Caio Bianchi]

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

—
You are receiving this because you commented.

[Christian Brabandt]

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

—
You are receiving this because you commented.

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

—
You are receiving this because you commented.

[R0b0t1]

On Sun, Apr 30, 2017 at 2:10 PM, Christian Brabandt
<vim-dev...@256bit.org> 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-dev ML]

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

—
You are receiving this because you commented.

[Christian Brabandt]

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.

—
You are receiving this because you commented.

[Christian Brabandt]

okay, asked authors for there permissions.

—
You are receiving this because you commented.

[Christian Brabandt]

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

—
You are receiving this because you commented.

[Jay]

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.

—
You are receiving this because you commented.

[Herbizarre]

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

—
You are receiving this because you commented.

[Jay]

@vyp Added Vim license to disco.vim readme

—
You are receiving this because you commented.

[Romain Lafourcade]

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.

—
You are receiving this because you commented.

[Jay]

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

—
You are receiving this because you commented.

[Romain Lafourcade]

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

—
You are receiving this because you commented.

[Hiroki Kokubun]

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

• Nord
• 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)

—
You are receiving this because you commented.

[Jay]

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

—
You are receiving this because you commented.

[Hiroki Kokubun]

@jsit Ah, you're right. I edited my list, thank you for the comment.

—
You are receiving this because you commented.

[xero harrison]

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.

[Romain Lafourcade]

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.

[Christian Brabandt]

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

[Tony Mechelynck]

«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. ;-)

[Romain Lafourcade]

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!

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

[Daniel Nathan Gray]

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.

[Wang Shidong]

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.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub, or unsubscribe.

[Christian Brabandt]

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

[wsdjeg]

1) It is hard to determine which one is nice looking colorscheme.

2) agree.

[Romain Lafourcade]

So, @chrisbra, were are on this topic and the related #4996? @lifepillar and me 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?

[Christian Brabandt]

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

[Christian Brabandt]

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!

[Romain Lafourcade]

That's too bad. Good luck for whatever you are doing, @lifepillar.

Le mar. 5 mai 2020 à 22:33, Lifepillar <notifi...@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

> <https://github.com/vim/vim/issues/1665#issuecomment-624290938>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AACUCD3E7ZEZX2QDFGWRUV3RQBZZVANCNFSM4DJPMCBQ>
> .
>


--
Romain Lafourcade

[Bram Moolenaar]

Closing in favor of PR #9795

—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you commented.Message ID: <vim/vim/issues/1665/1044539876@github.com>

[Christian Brabandt]

Closed #1665.

—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.

You are receiving this because you commented.Message ID: <vim/vim/issue/1665/issue_event/6109399535@github.com>