Open Weissle opened 11 months ago
The Hop plug-in seems to be using quite a few different highlight groups based on their docs. Maybe one of them links to a core highlight group which doesn't work well in this context, or which is set to a color that conflicts with the Gruvbox Material palette.
I need to install the plug-in and optimize it. Meanwhile if you come up with suggestions feel free to share!
https://github.com/sainnhe/gruvbox-material/blob/7f56d9f9c4860df528031539d321a61f6e081dee/colors/gruvbox-material.vim#L1230 I think gruvbox overrides the highlights in here.
I just noticed the gradients for multi-letter matches:
To better support this and similar plugins, we have to pick colors which:
Search
(green), so a shade aqua-green
isn't an optionCurSearch
/IncSearch
(red), so a shade red-orange
isn't an optionPurple doesn't look great with CurSearch
:
Yellow doesn't look great with Search
:
Blue doesn't look great with Search
:
Disclaimer: the Everforest colorscheme was used in my screenshots, but both themes have similar color semantics and palette design.
I'm wondering whether we shouldn't instead have an option to reduce the contrast of Search
and CurSearch
, so that this type of "quick jump" plugins play nicer with search highlights. Something like this was suggested in https://github.com/sainnhe/sonokai/issues/36#issuecomment-1518897205 (see the second set of screenshots with search highlights).
CurSearch is not important because people use hop to jump to remote places.
Sure, but so is Search
then, isn't it? I could argue that the search results have nothing to do with Hop, and that the easiest "fix" is to clear search results before toggling a hop.
If you search for some characters in Neovim, the match you last jumped to will be highlighted in red, which will inevitably lead to invisible characters as well if not optimized correctly.
and that the easiest "fix" is to clear search results before toggling a hop.
That's current my solution. Usually, I search for something, run <cmd>noh<cr>
, and use hop to jump to there.
If you search for some characters in Neovim, the match you last jumped to will be highlighted in red, which will inevitably lead to invisible characters as well if not optimized correctly.
The hint in CurSearch is not important because our cursor already around there. Right?
OK fair, thanks for your input! 🙌
I'll submit a PR and tag you on it before merging.
@Weissle sorry for the delay. I finally found the time to experiment with the plugin a little more.
Here is what a color optimization would look like if we wanted to play nice with Search
highlights:
I'm not particularly happy about it. This is less visually consistent than our current green-orange defaults (your original screenshot), the only advantage is that the Search
edge case is now covered and characters inside searched expressions are visible.
```lua -- Apply custom highlights on colorscheme change. -- Must be declared before executing ':colorscheme'. local grpid = vim.api.nvim_create_augroup('custom_highlights_gruvbox_material', {}) vim.api.nvim_create_autocmd('ColorScheme', { group = grpid, pattern = 'gruvbox-material', callback = function() local config = vim.fn['gruvbox_material#get_configuration']() local palette = vim.fn['gruvbox_material#get_palette'](config.background, config.foreground, config.colors_override) local set_hl = vim.fn['gruvbox_material#highlight'] set_hl('HopNextKey', palette.purple, palette.none) set_hl('HopNextKey1', palette.red, palette.none) set_hl('HopNextKey2', palette.orange, palette.none) end }) ```
An alternative I suggested earlier is to instead modify the Search
background highlight color to something less contrasted:
In my opinion this is a lot nicer than what the above is trying to achieve. By using a less contrasted background color for searched expressions, we have a better guarantee that EasyMotion-like plugins—such as Hop—are not going to interfere with search results.
It would probably be useful if the colorscheme had an option to enable this (search_highlight_contrast
, search_highlight_style
, etc.), meanwhile I'm including a Neovim snippet that you can try including inside your own config.
Feedback welcome!
```lua -- Apply custom highlights on colorscheme change. -- Must be declared before executing ':colorscheme'. local grpid = vim.api.nvim_create_augroup('custom_highlights_gruvbox_material', {}) vim.api.nvim_create_autocmd('ColorScheme', { group = grpid, pattern = 'gruvbox-material', callback = function() local config = vim.fn['gruvbox_material#get_configuration']() local palette = vim.fn['gruvbox_material#get_palette'](config.background, config.foreground, config.colors_override) local set_hl = vim.fn['gruvbox_material#highlight'] set_hl('Search', palette.none, palette.bg_visual_yellow) set_hl('IncSearch', palette.none, palette.bg_visual_red) end }) ```
thanks. I will try it for few days and write the feedback here.
I think the first solution would be better. The second solution effects the users who don't use hop.nvim and the search highlight is not so visible. Thanks.
I have done the following steps before reporting this issue:
Operating system/version
WSL Ubuntu20.04
Terminal emulator/version
Windows terminal 1.18.3181.0
$TERM environment variable
tmux-256color
Tmux version
tmux 3.0a
Feature matrix
Minimal vimrc that can reproduce this bug.
Steps to reproduce this bug using minimal vimrc
search a word. move the cursor away from it. The searched word is highlighted. runHopWord. The hint in the searched word is invisible.
Expected behavior
"smoka7/hop.nvim"'s default highlight seems better. I deleted the highlight defined in gruvbox then got below highlights.
Actual behavior
The hint in the searched word is invisible.