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]

Nvim seems use underline in cterms:

thanks but i added two new colors anyway for terminal colors and diff

[habamax]

did you change matchparen?

I have just checked again the light 256

Here guess if I selected first opening ( or not.

[habamax]

I have checked 16c in xterm for other issues I mentioned earlier, looks good for me.

[habamax]

I have only 3 issues left:

1. MatchParen vs Visual
2. Spell* shouldn't use ctermul, it is not supported widely enough.
3. ansi terminal colors should be more readable

Once resolved, I will merge the colorscheme in.

@romainl if you have time, please try this one.

[habamax]

Is it the same in neovim?

Visual and IncSearch

[chrnz008]

Is it the same in neovim?

Visual and IncSearch

yes

[chrnz008]

did you change matchparen?

@habamax can i use red for matchparen like other colorschemes it is making harder to guess where the cursor is if i use a harder bg

[habamax]

did you change matchparen?

@habamax can i use red for matchparen like other colorschemes it is making harder to guess where the cursor is if i use a harder bg

Sure, why not.

[lifepillar]

Spell* shouldn't use ctermul, it is not supported widely enough.

To clarify this bit: Colortemplate (by design) emits the ctermul attribute every time a special color is defined. The idiomatic way to have a special color for the GUI, but none for <=256 colors is naturally to override the higroup definition for all <=256 color environments:

SpellBad none none s=baldFossa undercurl
/256/16/8 none none s=none underline

(It is also recommended to override undercurl with underline for better terminal compatibility).

As s=none is assumed by default (:help colortemplate-hi-groups), this is also fine:

SpellBad none none s=baldFossa undercurl
/256/16/8 none none underline

Btw, while looking at novum template, I have found a bug. It doesn't affect you if you follow the guideline above.

Edit: another alternative, if you prefer it, is:

SpellBad none none s=none      underline
    /gui none none s=baldFossa undercurl

[chrnz008]

@habamax could u check the readability for terminal colors

[habamax]

@habamax could u check the readability for terminal colors

looks ok for me.

[habamax]

Could you also change the Titlebar color for both light and dark?

It is the same as tabline/tablinefill

[habamax]

Spell* are still not fixed

novum:

darkblue as example (any other in repo would do too)

[habamax]

thx, do you think active/inactive should be other way around for light?

for dark you have brighter active, dimmer inactive

Here I am not insisting, it would be fine if you leave it as is.

[habamax]

just fyi, this is the command I use to check spell highlights:

command! ColoSpell run colors/sample/spell.vim

.vim/colors/sample/spell.vim

tabnew
setlocal spell
setlocal spelllang=en_ca
setlocal spellfile=$MYVIMDIR/colors/sample/en.utf-8.add
setlocal bufhidden=wipe buftype=nofile nobuflisted noswapfile

let s:text = "Colour. colour (Spell Cap), color (Spell Local), couleur (Spell Rare), kolour (Spell Bad)"

call setline(1, "Normal:  " .. s:text)
call setline(2, "String:  " .. s:text)
call setline(3, "Comment: " .. s:text)

syntax match sampleString "^String:.*$"
syntax match sampleComment "^Comment:.*$"

hi link sampleString String
hi link sampleComment Comment

[habamax]

Thx @chrnz008, merging it.

[chrnz008]

thx, do you think active/inactive should be other way around for light?

yes that's what i though initially but im restricted by the way light and dark colors are defined (they are just altered) and is there a way to override it just for one group??

[chrnz008]

also

should i change the cursorline (slate seems to do the same)

[chrnz008]

thanks @habamax @lifepillar @mao-yining

[habamax]

Thank you, @chrnz008, and please excuse my picky approach to the small details I would like to be fixed in the colorscheme before accepting it.

One of the goals of this interaction was to enable you as the one who would be able to handle similar reviews for other to-be included colorschemes in the future.

Great job!

[habamax]

thx, do you think active/inactive should be other way around for light?

yes that's what i though initially but im restricted by the way light and dark colors are defined (they are just altered) and is there a way to override it just for one group??

Well, you have full control on what color to use where. If there is not enough defined colors, define a new one and use it.

[habamax]

Create new PRs for the changes. Don't be strictly bound to what neovim has as a source, you have a new colorscheme that is inspired by it but you should be able to fix usability issues if you think it is necessary.

[habamax]

also should i change the cursorline (slate seems to do the same)

yes, I missed it as I don't use cursorline :)

Fix it please.