Vim colorscheme, separate repo, togglebg, 24bit RGB

[dngray]

I am thinking this could do with some work:

1. Available in a separate repository ie like altercation/vim-colors-solarized the reason for doing this is it can then easily be used by a plugin manager (vimplug etc).

2. I would consider modifying the togglebg script to work for all four schemes, light, dark, white, black.

3. I'd consider a 24bit RGB true color only variant for neovim-qt ie like JulioJu/neovim-qt-colors-solarized-truecolor-only

[dngray]

I am looking at adding a light, black, white theme to lightline.vim, looks like dark is already done. In my screenshots I used Solarized for the left side (with termite), and selenized-dark skin for the right (termite).

I am thinking this vim theme really needs some work, besides #33 #35 #39 which I have both verified are issues.

For example spelling/grammar should use red/blue wavy line as its much neater. The nice thing about the wavy line is it's obvious enough you can see it but not obtrusive enough that you turn it off. This means you can leave ":set spell on". I have fixed a few typos so I think that's something nobody in particular might want to look into 🙂 @jan-warchol I am not sure however if you can do that with urxvt. I think this only works in terminals that use vte, or that have implemented it like kitty.

I used to be a long time urxvt user. I have recently decided however to give up on it. rxvt-unicode uses libxft which means that it will likely never able to be run as a Wayland native application, something I am now considering since I've started using sway.

After working on a11y particularly in regard to blindness, I noticed that these types of applications are absolutely unusable with a screen reader. As are ones which use libxcb, eg Rofi. Even though I really like Rofi, I have turned termite into a floating launcher for that reason. Could also use bemenu I guess.

To get urxvt working correctly, with extra gylphs, one has to set backup fonts, even with that I have only had marginal success.

Then other things like cut and paste and clickable URLs need special configuration and crufty perl scripts.

All in all, I start to question the efficiency gained from using such a minimal terminal. /end rant

Ie see this example (the color test can be run with :runtime syntax/colortest.vim).

We should also have a true-color theme for those that use neovim-qt. This may effect things like gvim too. On the left we see the colors stay to what they should be.

However if we used the solarized theme (the one for terminal), we see this:

This means in total we will need 8 'themes', light, dark, black, white 16bit for terminal, and light, dark, black, white for 24bit RGB.

[jan-warchol]

Somehow I forgot to look into this one earlier - sorry!
Whoah! I see you put much thought into this <3 I definitely agree that vim scheme needs improvements, current version is quite limited. Please give me some time to it over :-)
In the meantime you may take a look at VSCode theme - I've been workinig on it recently and I'd say it's more complete than vim scheme currently.

[dngray]

Whoah! I see you put much thought into this <3

Out of all my themes, (n)vim is the most important 😀 (sorry emacs people), (though I do want to make sure a good emacs theme is available too).

It is the last thing stopping me switching my terminal over to selenized, because I so often use it.

Please give me some time to it over :-)
In the meantime you may take a look at VSCode theme - I've been workinig on it recently and I'd say it's more complete than vim scheme currently.

Will do, I kinda liked the way the solarized theme was with the code folds so I might try to cook something up similar to that.

[dngray]

Ideally it would be great if we could reduce this down to one file, selenized.vim and the "set background" option could be used to choose between light/dark/black/white.

I would be keen to not have a truecolor version if that can be avoided, as if we can get that to work in the main theme.

Perhaps these could also be of help:

• https://github.com/jacoborus/estilo
• https://github.com/romainl/vim-rnb
• https://github.com/ggalindezb/vim_colorscheme_template

I do like the format of the solarized.vim theme, with the code folds and that.

I think we could make use of "Alternate light scheme" and "optional contrast schemes" ie g:solarized_contrast for the black/white variant.

I am not however sure how we would do this with the palette colors having the same name. Ie br_green in the white palette is different to br_green in the dark palette.

I have stopped working on this until we can decide how we want to proceed.

[dngray]

It may not be necessary to have a separate color scheme, maybe we can do something like vim-solarized8, I have seen that particular 'solarized' variant used quite a lot these days.

The main reason for the existence of this project is that the original Solarized
theme does not define guifg and guibg in terminal Vim, making it unsuitable
for versions of Vim supporting true-color (i.e., 24-bit color) terminals.
Instead, this color scheme works out of the box everywhere. For the best
experience, you need:

• Vim ≥7.4.1799, or NeoVim, with termguicolors set, and
• a true-color enabled terminal.

Also, How to Create Proper Folding for Vim/Nvim Configuration

Turns out not all terminal emulators are going to be truecolor, urxvt and terminlogy being two of them. I guess if we did it like: vim-solarized8 it would fallback to the 256 color theme.

I also expect that vim-colortemplate could be very useful to us.

Would be great if we could get something included in vim/vim#1665

[dngray]

I have started mucking around with it here:

• vim_selenized_light_dark.colortemplate
• vim_selenized_black_white.colortemplate

I am a bit stuck though on the Violet and Orange colors and their bright versions. I seem to get an error when trying to specify those.

[lifepillar]

Colortemplate’s author here. Please see :help cterm-colors for the valid ANSI color names.

[dngray]

Colortemplate’s author here. Please see :help cterm-colors for the valid ANSI color names.

Ah okay, so for guicolors i will just say "Orange" and "Violet" because there is no "Light" version of that? It would have been nice to have all the colors defined for "completeness" sake even if only used in GUI mode.

Another question, is it possible to have all four variants in the same colortemplate, ie light, dark, black, white or should I keep them separate like that. We have four pallettes and when I tried to have anything but "light" and "dark" in the same file I got an error related to that. (Sorry a bit new to vim color scheming).

[lifepillar]

In Colortemplate, a Color definition consists of four parts, in this order: an arbitrary name, the GUI value (hexadecimal or RGB), a terminal value for terminal with at least more than 16 colors (typically, an integer between 0 and 255, or the special “inferred” value ~) and a value for terminals with at most 16 colors (which may be a number between 0 and 15 or a color name). The only acceptable values for the last column are those documented in :help cterm-colors.

In these definitions:

Color: orange               #c25d1e                ~        DarkOrange
Color: violet               #8762c6                ~        DarkViolet
Color: brightorange         #bc5819                ~        LightOrange
Color: brightviolet         #825dc0                ~        LightViolet

the last column has invalid color names. Note that whatever (valid) names you use, there is no guarantee that they will correspond to a particular color: that depends entirely on one's terminal settings. E.g., in my terminal, my current settings are like this:

If I used your color scheme with :set t_Co=16, I would get the colors shown in the screenshot above and nothing else. If I used, say, the Solarized palette for my terminal, I would get these colors:

Note that for Solarized, most colors in the “Bright“ line (colors 8–15) are in fact shades of gray, and bright magenta is actually violet (Solarized is a bad example of a terminal color palette).

Another question, is it possible to have all four variants in the same colortemplate, ie light, dark, black, white or should I keep them separate like that. We have four pallettes […]

You have two color palettes for dark background and two color palette for light backround, so IMO the cleanest approach is to use two independent colortemplate files and generate two independent color schemes. For example:

# Template 1 (Selenized dark/light)
# [...]
Variant: gui 256 8

Background: dark
Color: bg #103c48 ~ Black
Color: black #184956 ~ DarkGray
# etc... (other color defs and highlight groups)

Background: light
Color: bg #fbf3db ~ White
Color: white #ece3cc ~ LightGray
# etc… (other color defs and highlight groups)

and

# Template 2 (Selenized black/white)
# [...]
Variant: gui 256 8

Background: dark
Color: bg #181818 ~ Black
Color: black #252525 ~ DarkGray
# etc...  (other color defs and highlight groups)

Background: light
Color: bg #ffffff ~ White
Color: white #ebebeb ~ LightGray
etc…  (other color defs and highlight groups)

You might put everything in a single template, though: in that case, you most likely would need to define a user option to select dark/light vs black/white. For example:

# Unified template (dark/black + light/white)
# [...]

#let g:selenized_contrast = get(g:, 'selenized_contrast', 'dark')

Variant: gui 256 8

Background: dark
Color: dark_bg #103c48 ~ Black
Color: dark_black #184956 ~ DarkGray
Color: black_bg #181818 ~ Black
Color: black_black #252525 ~ DarkGray
# etc... (other color defs)

#if g:selenized_contrast == 'dark'
  Normal dark_fg dark_bg
#else
  Normal black_fg black_bg
#endif

# etc…

Background: light
# Do something similar to the above for light/white colors

when I tried to have anything but "light" and "dark" in the same file I got an error related to that

The Background directive is directly related to :help 'background'. The only values for 'background' are dark and light (the Background directive also accepts any).

a bit new to vim color scheming

I recommend reading :edit $VIMRUNTIME/colors/README.txt. And Colortemplate's extensive documentation, if you plan to use it ;)

Edit: sent incomplete reply!

[dngray]

wow I was not expecting a reply like that 😄

I have been having a look over colortemplate.txt I got lost in a few spots particularly around the highlight group stuff. I have decided to just start on the dark and light variant of selenized.

I should be able to use most of the same file to do the black and white version later.

Your template plugin does look like it will produce a nice clean theme definition. I would very much like to use it. I am sure @jan-warchol will agree.

In Colortemplate, a Color definition consists of four parts, in this order: an arbitrary name, the GUI value (hexadecimal or RGB), a terminal value for terminal with at least more than 16 colors (typically, an integer between 0 and 255, or the special “inferred” value ~) and a value for terminals with at most 16 colors (which may be a number between 0 and 15 or a color name). The only acceptable values for the last column are those documented in :help cterm-colors.

I guess I can just not set the last column. I know it won't be used.

What I am wondering is how I should set the foreground/background, those colors are different. For example with the dark variant. I read the section there in colortemplate-background but it still wasn't immediately obvious to me what I was doing wrong. Should the black declaration on that line and below be set to none?

I am getting a weird background which appears to be #005f5f:

In the case of selenized dark it should be #103c48. ie selenized_dark_light.colortemplate

I was trying to get that sorted out before mucking around with the Foreground/Background part of the highlight group.

My termite config configuration has them set. For some reason though It does not look right at all :( I know that I haven't yet configured the definitions for all variants.

Also is there a pros/cons to setting the definition with rgb() in the pallette as opposed to the shorter hexadecimal value? I was curious about that.

Note that for Solarized, most colors in the “Bright“ line (colors 8–15) are in fact shades of gray, and bright magenta is actually violet (Solarized is a bad example of a terminal color palette).

Ah yes I'm aware of that, in fact it is mentioned there.

You have two color palettes for dark background and two color palette for light backround, so IMO the cleanest approach is to use two independent colortemplate files and generate two independent color schemes. For example:

# Template 1 (Selenized dark/light)
# [...]
Variant: gui 256 8

Background: dark
Color: bg #103c48 ~ Black
Color: black #184956 ~ DarkGray
# etc... (other color defs and highlight groups)

Background: light
Color: bg #fbf3db ~ White
Color: white #ece3cc ~ LightGray
# etc… (other color defs and highlight groups)

and

# Template 2 (Selenized black/white)
# [...]
Variant: gui 256 8

Background: dark
Color: bg #181818 ~ Black
Color: black #252525 ~ DarkGray
# etc...  (other color defs and highlight groups)

Background: light
Color: bg #ffffff ~ White
Color: white #ebebeb ~ LightGray
etc…  (other color defs and highlight groups)

I think that might be the tidiest way to do it. It is likely anyway users would use light in day and dark at night, or white in day and black at night anyway.

I tried doing that https://github.com/dngray/vim-colortemplate/commit/e430deab8a7ae7247c4aeed3018784e6bd40df87 and got:

selenized_dark_light.colortemplate|53 col 8 error| 'bg' is a reserved name and cannot be overridden
selenized_dark_light.colortemplate|167 col 8 error| 'bg' is a reserved name and cannot be overridden

[jan-warchol]

I see I have a lot of catching up! Awesome :D

Before looking into details (and trying out colortemplate - thanks @lifepillar !), let me clarify some of my priorities:

• 256-color version of the scheme is the lowest priority for me, because by definition it can only be a rough approximation of the desired colors.
• support for ANSI-based scheme (i.e. the old-school way of configuring actual colors on the terminal emulator level and using ANSI codes in the scheme) is very important to me.
• the "bright" colors in selenized palette are sort of a side-effect - they are there so that coloring in terminal emulators make sense, but I don't intend to use them for code syntax highlighting.
• As I wrote here, "bundling" light and dark versions of the palette is only a nice-to-have for me. For me it's perfectly acceptable to have separate dark and light schemes (and requiring the user to switch terminal color profile in case of CLI vim).

With that said, I'll dive into actual scheme design now (I'll focus on selenized dark first).

[dngray]

With that said, I'll dive into actual scheme design now (I'll focus on selenized dark first).

I guess I should leave this to you then, as you'd have a specific way you like things 😁 I was thinking you might have been too busy to do it.

[jan-warchol]

@dngray @lifepillar ok, did some pondering and I think I know how to proceed.

Your template plugin does look like it will produce a nice clean theme definition. I would very much like to use it. I am sure @jan-warchol will agree.

Absolutely! From what I see, colortemplate supports both truecolor (for GUI versions of vim) and ANSI codes (for "old" approach with setting color palette inside terminal), and more. This is just what we need - thank you!

I guess I should leave this to you then, as you'd have a specific way you like things I was thinking you might have been too busy to do it.

Actually there are a lot of things for which I could use a second opinion, so please do feel invited! And in fact I am quite busy, so it's good to join forces.

I'd like to start by adapting the draft that I already have to colortemplate format, focusing on "dark" variant of selenized first (I'd like to work on handling different variants after we have an initial version of dark one and I try it out for a few days). I see that you already did some tests, would you like to turn them into a PR? I can also do this myself in the evening.

[dngray]

I guess I should leave this to you then, as you'd have a specific way you like things I was thinking you might have been too busy to do it.

Actually there are a lot of things for which I could use a second opinion, so please do feel invited! And in fact I am quite busy, so it's good to join forces.

What you've written in #58 is a good start. A general editor agnostic guideline would be good when it comes to keeping consistency across the various editors.

I'd like to start by adapting the draft that I already have to colortemplate format, focusing on "dark" variant of selenized first (I'd like to work on handling different variants after we have an initial version of dark one and I try it out for a few days). I see that you already did some tests, would you like to turn them into a PR? I can also do this myself in the evening.

I have been using your draft the last few days and I do like it. I do think we could do better for Vim Suggestions #33 (I consider #35 and #39 to be bugs also).

I'm not sure if this is possible, but can we have tty compatibility? I understand colors there are going to be limited, but as long as they are readable that would be nice. Consistency with (n)/vim in console and nvim-qt/gvim would also be good.

In the tty the blue in the double quotes is unreadable, (shell script). This might be necessary if X/Wayland won't start. I wonder if we can think of a solution that can solve this but still be appropriate for terminal/graphical vim.

I wasn't able to solve the background issue mentioned in #47 (comment) so I'm wondering if @lifepillar might have some tips there.

I will work on adapting the things from that draft into the colortemplate and then put it in a PR.

[dngray]

I have had a bit of a go with the initial coloring. Not sure how to set ctermbg=8, that's not a defined color, but it will be needed for MatchParen and Visual. It's time for me to 💤 now.

[lifepillar]

I am getting a weird background which appears to be #005f5f […] In the case of selenized dark it should be #103c48.

How have you determined that the background is #005f5f? I have downloaded and built your selenized_dark_light.colortemplate:

1. neither #005f5f nor #103c48 appear among the color directives in the template;

2. Normal is defined to have white foreground and black background (when the …transp_bg option is not set), where white is #72898f and black is #184956;

3. accordingly, after loading your color scheme, the output of :hi Normal is:

    Normal   xxx guifg=#72898f guibg=#184956
   

So, the output is as expected. I guess your issue is related to:

I tried doing that dngray/vim-colortemplate@e430dea and got:
selenized_dark_light.colortemplate|53 col 8 error| 'bg' is a reserved name and cannot be overridden

Color names in color directives are (almost) arbitrary names, but Colortemplate does not allow you to call a color bg or fg. This is because bg and fg are valid values in Vim, and having colors with those names would be confusing. Use something like bgcol or bgcolor instead.

Try adding to your template:

Color: bgcol #103c48 ~
# etc…
Normal white bgcol
# etc…

Also is there a pros/cons to setting the definition with rgb() in the pallette as opposed to the shorter hexadecimal value?

No, they are equivalent: use the form you prefer. Incidentally, if you put the cursor on a Color: line and press ga, you will see both values (plus other info).

"bundling" light and dark versions of the palette is only a nice-to-have for me.

@jan-warchol This is what I recommend you do. Colortemplate directly supports that (see templates/dark_and_light.colortemplate in the plugin folder). The canonical way for a user to switch from dark to light background and vice versa is :set background=light or :set background=dark.

As far as I have understood, Selenized comes with two dark backgrounds and two light backgrounds: that's effectively two different color schemes and, although you may bundle everything in a single file, my suggestion above was to keep the two variants (dark/light and black/white) as two distinct color schemes.

[dngray]

# Template 1 (Selenized dark/light)
# [...]
Variant: gui 256 8

Background: dark
Color: bg #103c48 ~ Black
Color: black #184956 ~ DarkGray
# etc... (other color defs and highlight groups)

Background: light
Color: bg #fbf3db ~ White
Color: white #ece3cc ~ LightGray
# etc… (other color defs and highlight groups)

Dark/Light Variant

https://github.com/dngray/selenized/blob/pr_vim/utils/templates/vim/selenized_dark_light.colortemplate

Dark:

1. If I do this what about brightblack also being set to DarkGrey ie #2d5b69?

2. There now will also be two DarkGrey Base16 colors, ie Black and BrightBlack

3. What would I set the base16 color to for the fgcol attribute ie #adbcbc

Light:

1. If I set White to #ece3cc (LightGrey) then what would I set real-white too, ie #909995? Would Black be then set to #909995? ie reverse?

2. There now will also be two White Base16 colors, ie background and brightwhite

Black/White Variant

https://github.com/dngray/selenized/blob/pr_vim/utils/templates/vim/selenized_black_white.colortemplate

Black (dark):

1. If I set black to DarkGrey what would I set brightblack ie #3b3b3b to?

2. There now will also be two DarkGrey Base16 colors, ie Black and BrightBlack

White (light):

1. If I set White to #ebebeb (LightGrey) then what would I set real-white too, ie #878787? Would Black be then set to #878787? ie reverse?

2. There now will also be two White Base16 colors, ie background and brightwhite

Maybe @jan-warchol can just see if that's correct. I think I confused myself a bit.

I am getting a weird background which appears to be #005f5f […] In the case of selenized dark it should be #103c48.

How have you determined that the background is #005f5f? I have downloaded and built your selenized_dark_light.colortemplate:

1. neither #005f5f nor #103c48 appear among the color directives in the template;

2. Normal is defined to have white foreground and black background (when the …transp_bg option is not set), where white is #72898f and black is #184956;

3. accordingly, after loading your color scheme, the output of :hi Normal is:

   Normal   xxx guifg=#72898f guibg=#184956
   

I used the color picker in gimp to determine what the the color was #005f5f. I guess that was a terrible idea in hindsight.

"bundling" light and dark versions of the palette is only a nice-to-have for me.

@jan-warchol This is what I recommend you do. Colortemplate directly supports that (see templates/dark_and_light.colortemplate in the plugin folder). The canonical way for a user to switch from dark to light background and vice versa is :set background=light or :set background=dark.

Seems the most logical to new users too. It also fits in ideally with the use case apas 4 months ago described:

I use Solarized Light during the day and Dark during the night; I’ve written how I automated switching between the two on my blog. If I had to choose just one, I’d choose Light.

Ideally I want to do something similar to that because I want to become more accustomed to using light themes, I am just so used to dark versions! I think it might be a healthier choice (I do not have astigmatism and always work with a light on; never in the dark). [1] [2], [3].

[dngray]

We really need to get on with this, it would also fix #60

I have been a bit busy of late, any chance you will have a go at it @jan-warchol I have it on my to-do list but haven't gotten to it.

[jan-warchol]

Hi Daniel, great to hear from you! I've also been busy, and this week I'm preparing a lecture about git, but I should have time next week. From what I remember the next step for me is to check lifepillar's colortemplate on vim 8 - I think I'll manage to do that. pon., 21 paź 2019 o 19:16 Daniel Nathan Gray <notifications@github.com> napisał(a):

…

We really need to get on with this, it would also fix #60 <#60> I have been a bit busy of late, any chance you will have a go at it @jan-warchol <https://github.com/jan-warchol> I have it on my to-do list but haven't gotten to it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#47?email_source=notifications&email_token=AAKODPGFLP6EJR4QPJ5TZFTQPXPYTA5CNFSM4IJESPB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB3C7NY#issuecomment-544616375>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKODPEXJDUTJK7BAVU7MZTQPXPYTANCNFSM4IJESPBQ> .

[dngray]

From what I remember the next step for me is to check lifepillar's colortemplate on vim 8 - I think I'll manage to do that.

That does seem to be the case. I was having a bit of trouble #47 (comment) and also #47 (comment)

[jan-warchol]

Okay, I managed to get colortemplate running on my system. That's not much, but it's a start.

[jan-warchol]

Hi @dngray, over the last few days I've explored colortemplate and did some groundwork for scheme design. This week(end) I'll move on to the issues you were having. Thanks!

[dngray]

Hi @dngray, over the last few days I've explored colortemplate and did some groundwork for scheme design. This week(end) I'll move on to the issues you were having. Thanks!

I'm really quite pleased you found time. I struggled a bit it my self, but it looks very well designed. @lifepillar has done some tremendous work and it really should help us with our 4 variants. (light/dark) and (black/white).

Also not sure what the issue is (whether it was an update to the theme) or neovim, but it completely broke in nvim-qt hopefully colortheme can help us with truecolor (nvim-qt)

[dngray]

Did you end up making any progress with this?

[jan-warchol]

Hi Daniel, first: sorry for late reply. I'm in the middle of changing jobs and the process is quite stressful. second: the answer is "sort of". I had decided that I need to have a better understanding of how themes should be designed (i.e. token-color mappings) before creating vim colorscheme, and I went on to explore that. It turned into something much bigger than initially planned, and the result is this project: https://github.com/jan-warchol/limestone-colors Now, I'd *like *to get back to making selenized work in vim, but honestly I'm not sure how I'll be able to combine it with job search. I hope that answers your question. Thanks for reminding me about this issue! Janek wt., 18 lut 2020 o 10:37 Daniel Nathan Gray <notifications@github.com> napisał(a):

…

Did you end up making any progress with this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#47?email_source=notifications&email_token=AAKODPH3V3O337GTRIXJX23RDOT7FA5CNFSM4IJESPB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMBIEOI#issuecomment-587366969>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKODPEZOHLUJUESSOT4CXTRDOT7FANCNFSM4IJESPBQ> .

[dngray]

first: sorry for late reply. I'm in the middle of changing jobs and the
process is quite stressful.

I can imagine...

It turned into something much bigger than initially planned, and the result is this
project: https://github.com/jan-warchol/limestone-colors

That limestone theme looks quite pleasant, I will be sure to keep an eye on it!