add nvim_dark

[chrnz008]

ive followed the steps mentioned in #287
but im not sure what to remove and colortemplate is not picking up the statusline color correctly so ive changed the color.vim file manually
it also in vim9script even though i set the target to viml

[lifepillar]

colortemplate is not picking up the statusline color correctly

This is the StatusLine that is generated by the template:

StatusLine     xxx term=reverse cterm=reverse ctermfg=236 ctermbg=251 gui=reverse guifg=#2c2e33 guibg=#c4c6cd

That matches your template definition:

Color: weakSnail #2c2e33 ~
Color: zanyDingo #c4c6cd ~

StatusLine weakSnail  zanyDingo   reverse

What do you expect?

i set the target to viml

I don't see where that is done. You have to add this metadata line to the template:

Options: backend=vim

[chrnz008]

@lifepillar the statusline should be

hi StatusLine guifg=#2c2e33 guibg=#c4c6cd guisp=NONE gui=NONE ctermfg=236 ctermbg=251 cterm=NONE term=reverse

but colortempate is picking up

hi StatusLine guifg=#2c2e33 guibg=#c4c6cd guisp=NONE gui=reverse ctermfg=236 ctermbg=251 cterm=reverse term=reverse

i faced a similar issue with colorcolumn

I don't see where that is done. You have to add this metadata line to the template:

sorry i might have accidentally removed that while cleaning the nvim groups

[lifepillar]

You should remove the reverse attribute then.

[chrnz008]

colors is requested in `Environments` then Colortemplate uses the base-256
color value if such value is less than 16; otherwise, the color is set to
`NONE`.

@lifepillar is there a way to explicitly set NONE
and please review the latest changes (sorry if im annoying).

[lifepillar]

The Color directive in a template defines, well, a color: that cannot be “none”, because “none” means the lack of a color. When you define a highlight group in a template, you may specify none to set the corresponding color attribute to NONE, or omit to omit the definition entirely (in which case the color is inherited from another definition). For example:

Normal white none

will set the background color of Normal to NONE. If you want to do that only for some environment—say, for 256-color terminals—you may use overrides:

Normal white black   ; <-- Default definition has black background
Normal/256 white none  ; Applies only to 256-color terminals: no background (“transparent”)

Btw, the Environments directive is your template is:

Environments: gui 256 0

That should be:

Environments: gui 256 16 8 0

to also support less capable terminals. Edit: And, accordingly, you should define the base-16 value of each color.

[chrnz008]

@lifepillar could you review the changes

[lifepillar]

Overall, it looks fine to me in GUI and 256-colors. What's still missing is the color values for terminals with 16 colors or less: you may see how the color scheme looks in such environment by setting t_Co, e.g.:

:set notermguicolors
:set t_Co=8

At the moment, the color scheme is broken in those environments because all the attributes are set to NONE.

See any of the templates in this repository: such colors are usually specified by name (black, red, etc…) and the allowed names are described in :help cterm-colors.

@habamax @romainl Any comments on this proposal?

[chrnz008]

hat's still missing is the color values for terminals with 16 colors or less:

done!!

[lifepillar]

There's probably some work to be done there to improve consistency. This is how the color scheme looks like in my terminal with different settings of t_Co:

• :set t_Co=256

• :set t_Co=16

• :set t_Co=8

You may also add this at the end of the template to provide a fallback for terminals with no colors:

Include: _tcozero

as is done by (all, I think) the color schemes in this repo.

[chrnz008]

@lifepillar is there a way to test how the colors look for 16 and 8 color terminals cuz they may depend on the colorscheme used by the terminal itself and the colors look fine in my terminal

[lifepillar]

Have you :set notermguicolors before setting the value of t_Co?

[lifepillar]

they may depend on the colorscheme used by the terminal itself

8/16 colors are set on a “best effort” basis, because there is no guarantee how those colors are actually displayed in a given terminal. When designing for 8/16 colors you hope that the terminal's color palette is “sensible”, which means that (for a dark theme) color 0 is assumed to be close to black, color 1 is assumed to be approximately red, and so on. But of course there is no guarantee that this is the case. You should test with a few different terminal palettes, and choose palettes that are “sensible” in the previous sense.

I may have not chosen the best terminal colors in my screenshots above, but even when using other terminals there are a few things that can be improved, such as the contrast in the toolbar when t_Co is 16, or the contrast of search matches.

[chrnz008]

@lifepillar could u check now

[lifepillar]

I think these can still be improved:

Specific for t_Co=16

• the contrast in the toolbar's buttons (ToolbarButton):

• The foreground for ErrorMsg (the color scheme is not using Black: I think that in some cases, such as ErrorMsg, Black could be used to improve contrast):

• with :set hlsearch on, a search match at the cursor's position is not distinguished from other highlighted items (compare with t_Co=8 or t_Co=256, where the foreground color changes when the cursor is over a match):

Specific for t_Co=8

The 8-color variant seems dominated by a red/yellow tint, differently from the other variants, which use cold colors. Is that intentional? Personally, I would try to make it look more like the 16-color variant, though I understand that with so few colors it may get tricky.

All terminals

The Spell* highlight groups use undercurl , which in many terminals cause the text to blink. That should be replaced with underline for all variants except possibly GUI Vim.

The rest looks fine to me. Ah, please double-check that diffs are readable in all variants.

The check script (Colortemplate's Check button) reports that debugBreakpoint and debugPC are not defined. Those are probably not strictly required, but it would be nice if they were defined.

You may also run hitest.vim and inspect all highlight groups (that's how I spotted the issue with spell-checking groups). Execute :so $VIMRUNTIME/syntax/hitest.vim or just press the HiTest button in Colortemplate's toolbar.

[chrnz008]

@lifepillar I've changed all the suggested ones

• im ignoring the tabpanel hi groups as they are inhereting from tabline

about this:

The 8-color variant seems dominated by a red/yellow tint, differently from the other variants, which use cold colors. Is that intentional? Personally, I would try to make it look more like the 16-color variant, though I understand that with so few colors it may get tricky.

yes the colors look very dull and numb but, if i change the colors as needed wouldn't it look different from the colorscheme itself i mean can i keep my gui colors and fallback colors different is that allowed??

[lifepillar]

This is how I would proceed: comment out all /8 overrides in the template. Build the color scheme. Set notermguicolors and t_Co=8 then activate the color scheme. To me, it already looks better than with your overrides. Now, inspect all highlight groups (e.g., with HiTest) and uncomment or add /8 overrides for those that need to be fixed (for example, there are several that are not visible, like CursorLineFold, LineNr and many others—visual mode is broken, too). But, for example, I'd say that you don't need to define an override for Normal. And certainly you don't want it to have richBison (that is, DarkYellow) as the foreground color.

The overall idea is that your GUI/true color terminal version of the color scheme is your reference. As you reduce the number of available colors to 256, then 16, then 8, your goal is to try to be faithful to your reference as much as possible by making sensible adjustments where necessary. For 256 colors that is relatively easy. For 16 and 8 colors it becomes very hard if not outright impossible. You are very constrained, but you should strive to be faithful to your true color reference. Setting Normal foreground to DarkYellow is not faithful to your reference.

[chrnz008]

@lifepillar now ive realized the reason why i couldn't see the 8 colors was because there are no 8 colors on windows meaning whenever i do set t_Co=8 it is getting overrided to 16 again!!

even the legacy console host uses 16 colors

[romainl]

it is getting overrided to 16 again!!

What does that mean, exactly?

[chrnz008]

it is getting overrided to 16 again!!

What does that mean, exactly?

i can't technically view 8-bit colors like i can do on linux

vimt_Co.mp4

[romainl]

8c is not a different set of colors, it's just colors 0-7 of the current 16c color palette. So I'm not sure what you are expecting.

[chrnz008]

@romainl so is there no necessity for 8 bit colors to be specified in colorscheme??

[chrnz008]

@romainl so is there no necessity for 8 bit colors to be specified in colorscheme??

could u please the check the video i linked on previous comment

[romainl]

Use the following command:

:let &t_Co = 8

[chrnz008]

Use the following command:

:let &t_Co = 8

it is still getting changed to 16

[romainl]

I don't know what to say other than "it shouldn't". Best guess, something in your config forces 16 somehow.

Here, I can set t_co to any number without any reversion.

[chrnz008]

I don't know what to say other than "it shouldn't". Best guess, something in your config forces 16 somehow.

Here, I can set t_co to any number without any reversion.

i tried it with vim - u NONE and it still does the same thing.
The Win32 console supports 16 colors by default |dos-colors| this is mentioned in win32 section.

[romainl]

At a high level, the inability to set t_Co to something else than 16 in the Windows console sounds like a bug to me, as it can be set to any value everywhere else. I can't think of a valid reason to force t_Co like that only in this particular case.

At a lower level, the fact that the value you give is either ignored or reverted to 16 (this has to be cleared up somehow) would point to some runtime issue.

By the way, the right command is:

$ vim -u NONE

not:

$ vim - u NONE

Anyway, if the 8c branch of your colorscheme works on Linux, then I think you can call it a day. No need to check in the Windows console.

[chrnz008]

can you review the changes please

[lifepillar]

This is how it currently looks in my terminal with notermguicolors (Terminal.app, Clear Dark theme):

• 256 colors

• 16 colors

• 8 colors

Overall, I'd say great progress! It looks good enough to me.

I am ok with using color 3 (brownish) in the 8-color version to make up for the lack of color 8 (e.g., see LineNr or Comment), although I would have probably chosen color 7 instead.

Other than that, this seems ripe for merging. I don't have merge rights, so the last word is up to @habamax and @romainl.

[mao-yining]

@chrnz008 If you want to check 8 color on Windows, my solution is using msys2. Or you can use the vim in Git for Windows.