sainnhe / gruvbox-material

Gruvbox with Material Palette
MIT License
1.9k stars 164 forks source link

Diagnostic highlighting is hard to see in VIM TUI #176

Open Eval-99 opened 1 year ago

Eval-99 commented 1 year ago

The main problem and my fix

When g:gruvbox_material_diagnostic_text_highlighting is set to 1 there is some nice highlighting but in my opinion it can be pretty hard to see, especially when there is a lot of text on the screen. I added a new option that does not replace the old one called g:gruvbox_material_diagnostic_text_highlighting_high_contrast that boosts the contrast and makes things much more easy to read. You can look at the pictures I have added here to see the difference, in them coc-pyright is highlighting a syntax error and coc-spell is highlighting a spelling error.

I wanted to see if there was interest in a Pull Request. I don't have much experience with GitHub (and by "much" I mean no experience) so if I broke some rule or you have some advice for me, feel free to go ahead and tell me.

Before

1682203810

After

1682203834

antoineco commented 1 year ago

I assume the approach overrides the DiagnosticErrorText and similar highlight groups?

If that's the case, instead of having to combine multiple options to achieve this result (highlight + high contrast)—which can be quite unintuitive—I'd personally recommend using an autocmd to fine tune the few highlights that you need without having to fork or modify the color scheme.

In this specific case, you could even simply link DiagnosticErrorText to TSDanger which is identical to the highlight in your screenshot. TSWarning, TSNote and TSTodo are also available for highly contrasted yellow, green and blue.

-- Apply custom highlights on colorscheme change.
-- Must be declared before executing ':colorscheme'.
local grpid = vim.api.nvim_create_augroup('custom_highlights_gruvboxmaterial', {})
vim.api.nvim_create_autocmd('ColorScheme', {
  group = grpid,
  pattern = 'gruvbox-material',
  callback = function()
    local function hl_lnk(src, trgt)
      vim.api.nvim_set_hl(0, src, { link = trgt })
    end

    hl_lnk('DiagnosticErrorText', 'TSDanger')
    hl_lnk('DiagnosticWarnText',  'TSWarning')
    hl_lnk('DiagnosticHintText',  'TSNote')
    hl_lnk('DiagnosticInfoText',  'TSTodo')
  end
})
Eval-99 commented 1 year ago

@antoineco Correct me if I'm wrong but that looks like it's for Neovim, what I'm using is regular VIM. I tried using your suggestion (put it before :colorscheme and everthing) but it failed. Should I just use my edit and leave at that? I opened this issue in case there where other people that felt the same way I did.

antoineco commented 1 year ago

Appreciate that you did!

And yes my example was for Neovim sorry. The equivalent in Vim script is:

(edited)

" Apply custom highlights on colorscheme change.
" Must be declared before executing ':colorscheme'.
augroup custom_highlights_gruvboxmaterial
  autocmd!
  " high contrast diagnostics
  autocmd ColorScheme gruvbox-material 
  \       hi! link DiagnosticErrorText TSDanger  |
  \       hi! link DiagnosticWarnText  TSWarning |
  \       hi! link DiagnosticHintText  TSNote    |
  \       hi! link DiagnosticInfoText  TSTodo
augroup END

colorscheme gruvbox-material
Eval-99 commented 1 year ago

@antoineco No problem, and thanks a lot for taking the time to reply to me. It seems that this one also fails, but I was able to get it to work. Here is the modified version.

augroup custom_highlights_gruvboxmaterial
  autocmd!
  autocmd ColorScheme gruvbox-material
  \       hi! link ErrorText    TSDanger     |
  \       hi! link WarningText  TSWarning    |
  \       hi! link HintText     TSNote       |
  \       hi! link InfoText     TSTodo
augroup END

colorscheme gruvbox-material

Apparently VIM didn't like the single quotes. I also changed the group names for the ones I found in colors/gruvbox-material.vim and added the '!' to end of hl. Now that this is kind of solved should I close the issue or keep is open? What do you think?

antoineco commented 1 year ago

Thanks for fixing my poor Vim dialect :)

I would leave it open to gauge the interest. If there is demand we can maybe revamp the current option to accept other values than 0 or 1.