In syntax.c, do_highlight() tries to automatically set 'background'
when the Normal group's ctermbg is set:
if (t_colors < 16)
i = (color == 0 || color == 4);
else
i = (color < 7 || color == 8);
/* Set the 'background' option if the value is
* wrong. */
if (i != (*p_bg == 'd'))
set_option_value((char_u *)"bg", 0L,
i ? (char_u *)"dark"
: (char_u *)"light", 0);
The obvious problem with this is that for any terminal with 16 or more
colors, every color above 8 is considered light. Since many modern
terminals support 256 colors of varying brightness, this assumption
will be wrong about as often as it is right.
Maybe for terminals with more than 16 colors 'background' should be
left alone. Or, if the color is 16 or greater.
I think my preference would be to drop this code entirely and leave
'background' the way the user or the color scheme set it. I don't see
the advantage of this adjustment, and it has undesirable side-effects.
For example, if I use the color scheme darkblue, but I want to make an
adjustment to the background color, I might do this:
colorscheme darkblue
highlight Normal ctermbg=12
Not only does this fail to set the color I requested, it also unloads
the color scheme and leaves g:colors_name undefined. This appears to
be due to the code above changing 'background' to light, which causes
the color scheme to be reloaded (init_highlight() called from
did_set_string_option()), replacing my new background color.
Additionally, after reloading the color scheme did_set_string_option()
checks whether the color scheme changed the value of 'background', and
if so deletes g:colors_name and calls init_highlight() again.
Can we just get rid of this? Is there some benefit to it that I'm not seeing?
-Kevin
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
