ensure Todo highlight on dark bg is at least 233

[atweiden]

• note
  • existing s:dark_bg_2 handling is beneficial for hl-VertSplit
    • hence
      • this variable is kept in tact
• previously
  • with g:seoul256_background set to 233
    • todo syntax was rendered with dark background contrast
      • as bg colors dropped to #000000
• now
  • use the equivalent to light bg handling for dark bg todos
    • for equivalently balanced visual effect
    • see: s:light_bg_2

[junegunn]

with g:seoul256_background set to 233

• todo syntax was rendered with visually jarring effect

  • as bg colors dropped to #000000

Do you find it really bad? I think it looks okay.

[atweiden]

Reason for PR:

" s:light_bg_2 becomes background colour for |hl-Todo| when colorscheme
" is seoul256-light
"
" n.b. it cannot exceed 256, hence with |g:seoul256_light_background|
" set to 256, |hl-Todo| background colour matches seoul256-light
" background colour, thereby enabling opting out of background colour
" contrast
let s:light_bg_2 = min([s:light_bg + 2, 256])

" s:dark_bg_2 becomes background colour for |hl-Todo| when colorscheme
" is seoul256
"
" n.b. if |g:seoul256_background| is set to 233, |hl-Todo| background
" colour drops to 16 — this is noticeably higher contrast than in the
" seoul256-light corollary, where users can completely opt out of contrast
let s:dark_bg_2 = s:dark_bg > 233 ? s:dark_bg - 2 : 16

This PR should only affect users who set g:seoul256_background to 233.

I agree it’s better said to be a minor nitpick.

[junegunn]

thereby enabling opting out of background colour contrast

So the difference is only noticeable to the users who switch between light and dark modes, using 256 for the light background color, and 233 for the dark background. Anyone not using the exact combo will not notice the difference.

What I didn't understand at first was your initial expression visually jarring effect, because #000000 isn't much darker than 232, and such slight contrast is consistently present across higher g:seoul256_background values, except for 256.

256 is the only exception here, because 256 is the lightest color, and it's technically impossible to get a lighter background, but 233 is not #000000, so thankfully we can pick a darker color. This PR is suggesting that we should also make 233 an exception (no contrast). Maybe a better approach would be to support 16?

[atweiden]

So the difference is only noticeable to the users who switch between light and dark modes, using 256 for the light background color, and 233 for the dark background. Anyone not using the exact combo will not notice the difference.

Yes. Alas, I use seoul256-light for gvim and seoul256 for vim.

Maybe a better approach would be to support 16?

Support for 16 would be a welcome addition. 233 is perfectly fine, but either way.