Black on 256 colors being ignored

[jpesce]

First, kudos for the great project! Thanks for the time and effort on making this.

Now, for the bug:

When defining a base 256 color as 0 (code for terminal black) with Color and then setting a highlight to it, it gets ignored.

# Color name         GUI        Base256    Base16 (optional)
Color: black         #000000    0          Black

# Group              Foreground        Background        Attributes
EndOfBuffer          black             none

The generated colorscheme ignores the foreground color. The highlight group on the s:t_Co >= 256 section looks like this:

  hi EndOfBuffer ctermbg=NONE cterm=NONE

Probably 0 being evaluated as false somewhere?

Minimum working example:

# vim: ft=colortemplate
Full name:  Black Foreground Test
Short name: blackfg
Author:     Me <me@somewhere.org>

Variant:    256
Background: dark

# Color palette
Color:      black  #000000 0 Black
Color:      white  #ffffff 7 White

# Highlight group definitions
Normal white none
EndOfBuffer black none
# Etc…

Is compiled to:

" Name:         Black Foreground Test
" Author:       Me <me@somewhere.org>
" Maintainer:   Me <me@somewhere.org>
" License:      Vim License (see `:help license`)
" Last Updated: Wed Aug 26 17:35:08 2020

" Generated by Colortemplate v2.0.0

set background=dark

hi clear
if exists('syntax_on')
  syntax reset
endif

let g:colors_name = 'blackfg'

let s:t_Co = exists('&t_Co') && !empty(&t_Co) && &t_Co > 1 ? &t_Co : 2

if s:t_Co >= 256
  hi Normal ctermfg=7 ctermbg=NONE cterm=NONE
  hi EndOfBuffer ctermbg=NONE cterm=NONE      <--------------------------------
  unlet s:t_Co
  finish
endif

" Background: dark
" Color:      black  #000000 0 Black
" Color:      white  #ffffff 7 White
" vim: et ts=2 sw=2

The highlighted line should be compiled to:

  hi EndOfBuffer ctermfg=0 ctermbg=NONE cterm=NONE

[lifepillar]

Thanks for the detailed report! Your assessment is essentially correct. At some point, a comparison of the form 0 ==# 'some string' was performed and, suprisingly enough, in Vim such a comparison evaluates to true 🤨

Time permitting, I will review the code to eliminate such sloppy handling of types…

[lifepillar]

The reason is likely that comparisons of a number with a string are performed by parsing the string into a number, as in str2nr(). The latter returns 0 when the string does not represent a valid number.

I would have expected the opposite—that is, that 0 is turned into the string '0' 🤦‍♂️