sindrets/winshift.nvim

feat: Support for 256-color cterm highlights

tjkirch opened this issue · 6 comments

Howdy! I have a sort of graphical issue that I'm not sure how to debug.

When I use WinShift, the moving window's contents aren't highlighted, even though I'm using the config from the README that uses highlight_moving_win = true and focused_hl_group = "Visual". (I tried some other highlight groups and saw no difference.) What I actually see is that the gutter changes color, so line numbers turn white instead of my default grey, and the gutter is the same color as the rest of the window, instead of being a lighter grey like I usually have. I can still move the window around as expected, though.

When I use WinShift swap, I get the same effect in the gutter of the window I was in. No change in the other windows, except for the status bar being replaced by the window picker chars.

I've tried removing all my config, so init.vim just has the winshift plug line and its configuration, but it makes no difference. (I have no gutter in that case, so there's no change in appearance when I call WinShift, but it does still move windows around correctly.

I'm using Neovim 0.5.1 on Linux with the latest winshift, b5f5ac0. Any tips on what might be wrong would be appreciated!

Hm, sounds like the highlight groups are not being defined correctly. What's the output of:
:hi Visual | hi WinShiftNormal | hi WinShiftLineNr | hi WinShiftCursorLineNr?

:hi Visual | hi WinShiftNormal | hi WinShiftLineNr | hi WinShiftCursorLineNr                                                                                       
Visual         xxx ctermbg=237 guibg=#404040
WinShiftNormal xxx cleared
WinShiftLineNr xxx cleared
WinShiftCursorLineNr xxx cleared

I tried sourcing runtime/syntax/hitest.vim to test highlight groups, and Visual does appear correctly (the same way it does when I visually select). That's also where I got the name of some other highlight groups to try, ones that are very bold.

I'm not able to reproduce this. The only thing I suspect is that either you don't have termguicolors enabled, or something in your config is calling :hi clear. cterm highlights are not currently supported. If that's not the issue, I'm gonna need a minimal config that makes this reproducible.

Here's a template I used for testing
-- mini.lua
vim.cmd [[set runtimepath=$VIMRUNTIME]]
vim.cmd [[set packpath=/tmp/nvim/site]]
local package_root = '/tmp/nvim/site/pack'
local install_path = package_root .. '/packer/start/packer.nvim'
local function load_plugins()
  require('packer').startup {
    {
      'wbthomason/packer.nvim',
      'sindrets/winshift.nvim',
      -- ADD PLUGINS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
    },
    config = {
      package_root = package_root,
      compile_path = install_path .. '/plugin/packer_compiled.lua',
      display = { non_interactive = true },
    },
  }
end
_G.load_config = function()
  -- ADD INIT.LUA SETTINGS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
  vim.opt.nu = true
  vim.opt.termguicolors = true
  vim.opt.splitbelow = true
  vim.opt.splitright = true
  vim.cmd("colorscheme slate")
end
if vim.fn.isdirectory(install_path) == 0 then
  print("Installing dependencies...")
  vim.fn.system { 'git', 'clone', '--depth=1', 'https://github.com/wbthomason/packer.nvim', install_path }
end
load_plugins()
require('packer').sync()
vim.cmd [[autocmd User PackerComplete ++once echo "Ready!" | lua load_config()]]

To use it, call nvim --clean -u path/to/mini.lua.

I tested with nvim 0.6.0 and 0.5.1, and highlights were working correctly on (almost *) all the default colorschemes.

* I found an issue with highlights that use the reverse attribute. But your Visual didn't have that, so it shouldn't matter in your case.

don't have termguicolors enabled

Hmm, indeed, notermguicolors is set. I'm using urxvt (9.22) as terminal, which doesn't support 24-bit color; not sure if that's related.

Here's a template I used for testing

With that, I do see windows being highlighted during move. And termguicolors is set. (It's quite ugly; the "slate" colorscheme here doesn't look like it does in my normal config. Possibly tgc/24-bit related.)

If I just set termguicolors in my normal config, though, highlighting doesn't work, and it's quite ugly; I assume my colorscheme (jellybeans) doesn't support it.

I'll dig into this a bit more. Feel free to close the issue if you think this is an unsupported case.

I'm using urxvt (9.22) as terminal, which doesn't support 24-bit color; not sure if that's related.

@tjkirch It is related. This is the reason it wasn't working for you. The way I set up the highlights used to require true color support.

(It's quite ugly; the "slate" colorscheme here doesn't look like it does in my normal config. Possibly tgc/24-bit related.)

Haha, yes, I think all the default colorschemes are ugly. But that's besides the point, the minimal config was just to demonstrate that highlights were working under the right conditions. The reason "slate" looks different with and without termguicolors is because vim colorschemes have completely different color palettes defined for cterm and true color highlights. Further, since urxvt doesn't support true color, it has to make approximations of the 24-bit colors. And these approximations usually aren't very good.

Anyway, I decided to add support for the 256-color palette, so it should work correctly in 08e314f. I even tested with nanotech/jellybeans.vim and everything seems to be in order now. But just let me know if there's anything still not working as expected.

I have to say though: urxvt really is one of the only big terminals that still doesn't support true color. Even good ol' xterm supports it since years ago.

Thank you, it works perfectly! I have to say, this is some of the best software support I've ever received! 💯

urxvt really is one of the only big terminals that still doesn't support true color

Yeah. :( It's apparently been in the source for years now, but there hasn't been a new release made. It's sad. urxvt is the only terminal I've found that works the way I like. I'm sorry this caused trouble!