Error loading BG color

[afterefx]

Error detected while processing function <SNR>19_CSApprox[46]..<SNR>19_CSApproxImpl[46]..<SNR>19_SetCtermFromGui:
line   34:
E420: BG color unknown
Error detected while processing /Users/name/repos/dotfiles/vi/vim.symlink/bundle/csapprox/after/plugin/CSApprox.vim:
line   28:
E171: Missing :endif
Press ENTER or type command to continue

[godlygeek]

Was this with the latest GitHub master, or with the outdated vim.org version?

[afterefx]

This is with the GitHub master branch and using vim 8.0

VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Feb 11 2017 11:36:16)
MacOS X (unix) version
Included patches: 1-325

[redneb]

I have the exact same issue.

VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Mar  4 2017 05:12:05)
Included patches: 1-386

[jdevera]

Also affected. :he E420 says:

                                                    E419 E420
    When Vim knows the normal foreground and background colors, "fg" and
    "bg" can be used as color names.  This only works after setting the
    colors for the Normal group and for the MS-DOS console.  Example, for
    reverse video:
        :highlight Visual ctermfg=bg ctermbg=fg
    Note that the colors are used that are valid at the moment this
    command are given.  If the Normal group colors are changed later, the
    "fg" and "bg" colors will not be adjusted.

The language is a bit ambiguous, it could either mean you have to define Normal and be on MS-DOS or perhaps one of the two conditions is enough and that and should be an or (let us assume this).

CSApprox executes this before the error in my setup (Linux, btw):

hi SyntasticError cterm=NONE ctermbg=NONE ctermfg=NONE
hi SyntasticError ctermbg=231
hi SyntasticError ctermfg=16
hi Type cterm=NONE ctermbg=NONE ctermfg=NONE
hi Type ctermfg=29
hi Underlined cterm=NONE ctermbg=NONE ctermfg=NONE
hi Underlined ctermfg=62
hi Ignore cterm=NONE ctermbg=NONE ctermfg=NONE
hi Ignore ctermfg=bg

And here we see that it attempts to use bg before the Normal group has been set.

[jdevera]

In vim 7.4 the first settings are these:

hi Normal cterm=NONE ctermbg=NONE ctermfg=NONE
hi Normal ctermbg=231
hi Normal ctermfg=16

So something changed in the order, apparently

[jdevera]

I've changed CSApproxImpl to output some debug info before the loop call to SetCtermFromGui and it shows some strange behaviour:

echo "===="
echo string(s:hlid_normal)
echo string(hlID('Normal'))
echo synIDattr(s:hlid_normal, 'name')
echo "===="

I get this:

====
79
79
SyntasticError
====

I would have expected that last line to have output Normal

I hope this saves some time pointing the issue.

[godlygeek]

@jdevera I'm still not able to reproduce this (with Vim 8.0.427 on Linux), but your debugging is extremely helpful, and makes me suspect a Vim bug. I can't see any documented reason why

:echo synIDattr(hlID('Normal'), 'name')

would ever return anything other than Normal. If you run that command directly on the vim command line, do you see the same problem ("SyntasticError" instead of "Normal")?

Can you also try running:

:redir! >/tmp/synid_problem | sil hi | sil scriptnames | redir END

and upload the /tmp/synid_problem file that gets generated? I'm curious whether line 79 of the highlight groups list in that file will be "Normal" or "SyntasticError". I'm also hoping that seeing the list of plugins you're using might give me some hint why you can reproduce this and I can't (even after installing Syntastic, in case it was somehow relevant).

Also, are you also using the OS X vim version, or does this issue reproduce across platforms?

[godlygeek]

I managed to reproduce this, actually - it's definitely a vim bug. I've filed https://github.com/vim/vim/issues/1592 for it.

There's no obvious way to work around the problem in CSApprox, though... The only way I can think of would be to rewrite the entirety of s:Highlights to work by parsing the output of :highlight rather than by calling synIDattr, but that's both a big change and likely to have its own drawbacks... I'll need to think on it some more.

[godlygeek]

Actually, I may have spoken too soon - we can't solve this issue in general without parsing the output of :highlight, because I see no other way to get the name of a cleared highlight group in vim versions with this bug.

However, we can work around it for every builtin highlight group, since we know what their names are.

Can someone try the https://github.com/godlygeek/csapprox/tree/cleared_normal_workaround branch to confirm that it fixes the issue for them?

[jdevera]

I tried it. I got this:

Error detected while processing function <SNR>33_CSApprox[46]..<SNR>33_CSApproxImpl[12]..<SNR>33_Highlights:
line   49:
E716: Key not present in Dictionary: 0
Error detected while processing /home/jdevera/.vim/bundle/csapprox/after/plugin/CSApprox.vim:
line   28:
E171: Missing :endif
Press ENTER or type command to continue

[godlygeek]

Hm, ok... Can you try changing

if hlID(group) != hlID(synIDattr(hlID(group), 'name'))

To:

if hlID(group) > 0 && hlID(group) != hlID(synIDattr(hlID(group), 'name'))

[afterefx]

Been following the thread. Received the same error with the cleared_normal_workaround branch as jdevera. Changed it to

if hlID(group) > 0 && hlID(group) != hlID(synIDattr(hlID(group), 'name'))

as suggested and received the old error again:

Error detected while processing function <SNR>19_CSApprox[46]..<SNR>19_CSApproxImpl[46]..<SNR>19_SetCtermFromGui:
line   34:
E420: BG color unknown
Error detected while processing /Users/chris/repos/dotfiles/vi/vim.symlink/bundle/csapprox/after/plugin/CSApprox.vim:
line   28:
E171: Missing :endif
Press ENTER or type command to continue

[godlygeek]

@afterefx that's interesting... Can you disable CSApprox and upload the output of

:redir >/tmp/CSApprox | sil hi | redir END

That error, even after the proposed patch, suggests that the Normal group is just not set... I'd like to know what if anything the Normal group is set to by your color scheme.

[afterefx]

Here is the output on a gist

[jdevera]

I upgraded to Vim 8.0.535, this error no longer shows. This with csapprox on master branch.