Revise highlight logic to be simpler and obey user settings

[jsit]

I still think there's some inconsistency in this highlight logic that needs to be resolved. Here's a matrix of behaviors when different settings are set by the user:

master

	set_sign_bg 0	set_sign_bg 1
fg unset, bg unset	sets fg, sets bg	sets fg, sets bg
fg set, bg unset	does nothing	sets bg
fg set, bg set	does nothing	sets bg
fg unset, bg set	sets bg	sets bg

pr 729

	set_sign_bg 0	set_sign_bg 1
fg unset, bg unset	sets fg	sets fg, sets bg
fg set, bg unset	does nothing	sets bg
fg set, bg set	does nothing	sets bg
fg unset, bg set	does nothing	sets bg

In master, there are two scenarios where set_sign_bg is 0 and the background still gets set by the plugin.

Is this plugin trying to do too much for the user? Should it maybe just do:

execute "highlight default GitGutter".type." guifg=".guifg." ctermfg=".ctermfg." guibg=".guibg." ctermbg=".ctermbg

and if the user is setting colors themselves, then they can just take care of it on their own? Otherwise, I feel like this is the behavior we should maybe be seeing:

	fg unset	fg set
bg unset	sets fg, sets bg	sets bg
bg set	sets fg	does nothing

[airblade]

Sorry for the delay, I've been away.

master table: I think the final row's results are wrong: the code will set both the foreground and the background regardless of g:gitgutter_set_sign_backgrounds.

pr 729 table: as far as I can tell your PR doesn't use the g:gitgutter_set_sign_backgrounds variable, so I don't understand where the results in the "set_sign_bg 1" column come from. I would think the behaviour is always as per the "set_sign_bg 0" column.

In master, there are two scenarios where set_sign_bg is 0 and the background still gets set by the plugin.

You are right and when you put it like this, it sounds confusing ;) Two assumptions I never wrote down were:

• if someone has bothered to define GitGutter* highlight groups, they will have set the foreground colours;
• g:gitgutter_set_sign_backgrounds only applies to existing GitGutter* highlight groups.

Is this plugin trying to do too much for the user? ...if the user is setting colors themselves, then they can just take care of it on their own?

I think this is subjective. It certainly isn't necessary for the plugin to adjust the signs' background colours automatically and it makes the code more complicated. However, when changing colorschemes, I think it is helpful for the plugin to adjust the signs' backgrounds automatically to match the new sign column colour (admittedly only necessary if the user has defined GitGutter* highlight groups, not the colourscheme).

Having said all that, your final table looks ideal to me and I think we should make the plugin do that.

[airblade]

I'm closing this because I'm happy with the way the highlights and colours are handled, and nobody has reported any issues with highlights for years.

Thank you for taking the time to propose this change.