New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New colorschemes #1665

Open
0matgal0 opened this Issue Apr 28, 2017 · 34 comments

Comments

Projects
None yet
@0matgal0

0matgal0 commented Apr 28, 2017

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

This comment has been minimized.

Show comment
Hide comment
@chrisbra

chrisbra Apr 28, 2017

Member

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

Member

chrisbra commented Apr 28, 2017

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

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Apr 28, 2017

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 commented Apr 28, 2017

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

This comment has been minimized.

Show comment
Hide comment
@vim-ml

vim-ml Apr 29, 2017

vim-ml commented Apr 29, 2017

@brammool

This comment has been minimized.

Show comment
Hide comment
@brammool

brammool Apr 29, 2017

Contributor

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

brammool commented Apr 29, 2017

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

This comment has been minimized.

Show comment
Hide comment
@chrisbra

chrisbra Apr 30, 2017

Member

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

Member

chrisbra commented Apr 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@luchr

luchr May 2, 2017

So any suggestions what colorschemes should be bundled?

Solarized
see also vim-colors-solarized

luchr commented May 2, 2017

So any suggestions what colorschemes should be bundled?

Solarized
see also vim-colors-solarized

@CaioBianchi

This comment has been minimized.

Show comment
Hide comment
@CaioBianchi

CaioBianchi May 2, 2017

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

CaioBianchi commented May 2, 2017

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

@chrisbra

This comment has been minimized.

Show comment
Hide comment
@chrisbra

chrisbra May 2, 2017

Member

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

Member

chrisbra commented May 2, 2017

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

@luchr

This comment has been minimized.

Show comment
Hide comment
@luchr

luchr May 2, 2017

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 commented May 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@vim-ml

vim-ml May 2, 2017

vim-ml commented May 2, 2017

@lifepillar

This comment has been minimized.

Show comment
Hide comment
@lifepillar

lifepillar Jul 3, 2017

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:

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 commented Jul 3, 2017

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:

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

This comment has been minimized.

Show comment
Hide comment
@chrisbra

chrisbra Jul 5, 2017

Member

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.

Member

chrisbra commented Jul 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@chrisbra

chrisbra Aug 2, 2017

Member

okay, asked authors for there permissions.

Member

chrisbra commented Aug 2, 2017

okay, asked authors for there permissions.

@chrisbra

This comment has been minimized.

Show comment
Hide comment
@chrisbra

chrisbra Aug 2, 2017

Member

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

Member

chrisbra commented Aug 2, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@jsit

jsit Aug 2, 2017

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 commented Aug 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@vyp

vyp Aug 3, 2017

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 commented Aug 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jsit

jsit Aug 3, 2017

@vyp Added Vim license to disco.vim readme

jsit commented Aug 3, 2017

@vyp Added Vim license to disco.vim readme

@romainl

This comment has been minimized.

Show comment
Hide comment
@romainl

romainl Aug 5, 2017

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 commented Aug 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jsit

jsit Aug 5, 2017

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

jsit commented Aug 5, 2017

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

@romainl

This comment has been minimized.

Show comment
Hide comment
@romainl

romainl Aug 6, 2017

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 commented Aug 6, 2017

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

This comment has been minimized.

Show comment
Hide comment
@cocopon

cocopon Aug 7, 2017

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

Because they are...

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

cocopon commented Aug 7, 2017

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

Because they are...

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

This comment has been minimized.

Show comment
Hide comment
@jsit

jsit Aug 7, 2017

@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 commented Aug 7, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@cocopon

cocopon Aug 7, 2017

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

cocopon commented Aug 7, 2017

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

@xero

This comment has been minimized.

Show comment
Hide comment
@xero

xero Aug 7, 2017

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 commented Aug 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@romainl

romainl Aug 9, 2017

How many sorcerer derivatives do we need? ;-)

romainl commented Aug 9, 2017

How many sorcerer derivatives do we need? ;-)

@lifepillar

This comment has been minimized.

Show comment
Hide comment
@lifepillar

lifepillar Sep 23, 2017

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 commented Sep 23, 2017

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

This comment has been minimized.

Show comment
Hide comment
@chrisbra

chrisbra Sep 25, 2017

Member

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

Member

chrisbra commented Sep 25, 2017

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

This comment has been minimized.

Show comment
Hide comment
@tonymec

tonymec Sep 25, 2017

«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 commented Sep 25, 2017

«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

This comment has been minimized.

Show comment
Hide comment
@romainl

romainl Sep 25, 2017

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

romainl commented Sep 25, 2017

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

@lifepillar

This comment has been minimized.

Show comment
Hide comment
@lifepillar

lifepillar Sep 25, 2017

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 commented Sep 25, 2017

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

This comment has been minimized.

Show comment
Hide comment
@lifepillar

lifepillar Oct 1, 2017

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 commented Oct 1, 2017

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.

@k-takata k-takata added the runtime label Oct 12, 2017

@lifepillar

This comment has been minimized.

Show comment
Hide comment
@lifepillar

lifepillar Oct 28, 2017

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 commented Oct 28, 2017

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

This comment has been minimized.

Show comment
Hide comment
@venthur

venthur Nov 9, 2017

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 commented Nov 9, 2017

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

This comment has been minimized.

Show comment
Hide comment
@lifepillar

lifepillar Nov 21, 2017

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 commented Nov 21, 2017

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

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