Help with dropbar.nvim

[shyun3]

Hello, I'm running into an issue when using vimade with dropbar.nvim. As background, dropbar "dims" any of its bars in non-current windows by changing its highlights to darker ones (I think the code is in hlgroups.lua). But when vimade fades non-current windows, it seems like it deactivates the bar dimming and applies the fade on top of the result.

I tried adding blocklist rules for some of the relevant highlights (see README), but it seemed to have no effect. Does anyone have any ideas on what may be going on?

Some steps to reproduce:

1. Create the following repro.lua:

   local root = vim.fn.fnamemodify("./.repro", ":p")
   
   -- set stdpaths to use .repro
   for _, name in ipairs({ "config", "data", "state", "cache" }) do
     vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
   end
   
   -- bootstrap lazy
   local lazypath = root .. "/plugins/lazy.nvim"
   if not vim.loop.fs_stat(lazypath) then
     vim.fn.system({
       "git",
       "clone",
       "--filter=blob:none",
       "--single-branch",
       "https://github.com/folke/lazy.nvim.git",
       lazypath,
     })
   end
   vim.opt.runtimepath:prepend(lazypath)
   
   -- install plugins
   local plugins = {
     "Bekaboo/dropbar.nvim",
     "tadaa/vimade",
   }
   require("lazy").setup(plugins, {
     root = root .. "/plugins",
   })

2. Create some nested folders. This will make the resulting bars more prominent: mkdir -p test/dir
3. Create some files in the folders: touch test/dir/test{1,2}.c
4. Launch Neovim: nvim -u repro.lua test/dir/test1.c (this will create a .repro folder)
5. Close any Lazy pop-up windows and disable vimade for now: :VimadeDisable
6. Open the other file: :vs test/dir/test2.c. Note how the bar for test1.c is all gray:
   
7. Now enable vimade: :VimadeEnable. Note how the bar for test1.c is faded but has its colors applied:
   

Expected result
For the bar in test1.c to remain all gray, but faded.

[TaDaa]

Hi @shyun3 ! Thank you for the question/issue and detailed repro steps!

This should be covered by blocklist, but it can be a bit picky to configure. In your setup for vimade do something similar to the following.

If using lazy + opts:

return {{
'TaDaa/vimade',
opts = {
  recipe = {'default',  {animate = false}},
  blocklist = {
    extra = {
      highlights = {
        'WinBarNC', 'DropBarIconKindDefaultNC'
      }
    }
  }
}
}}

If using setup:

require('vimade').setup({
  recipe = {'default',  {animate = false}},
  blocklist = {
    extra = {
      highlights = {
        'WinBarNC', 'DropBarIconKindDefaultNC'
      }
    }
  }
})

It should be compatible with any recipes / other options you have as well, but let me know how that goes.

[shyun3]

I tried with those exact opts, but the result was the same

[TaDaa]

doh sorry about that can you see if the regex blocklist format gets you any closer?

highlights = {'/WinBar.*/', '/DropBar.*/'}

I think that may mostly work, but some of the icon toggling doesn't seem exactly right, but will have to look later in the evening

[shyun3]

Now it looks like the icons are still not gray and the bar isn't being faded at all:

[TaDaa]

appreciate your testing and input & sorry for the delay!

it seems like there is a need for blocklist to have different mechanisms for blocking. The way vimade is current blocklist is setup mostly for plugins not to dynamically change colors (which is counterintuitive!) - basically behind the scenes blocklist forces the current values to be preserved and doesnt really have much flexibility for other plugins manipulating things dynamically:

vimade/lua/vimade/highlighters/namespace.lua

Lines 184 to 186 in 266cb28

	hi.link = nil
	hi.name = nil
	vimade_highlights[name] = hi

That logic basically breaks anything that a blocked highlight links to and then forces it to get preserved. The reason it was done that way was to handle cases where a "blocked" highlight links to a color that is not blocked (in that case you'd still want the blocked color to be "blocked")

And then later there is logic to make sure highlights that link to a blocked highlight still get faded...

I think here in this scenario we need a mechanism to actually capture "completely don't touch this" or that the "highlight link needs to link to itself" (link to yourself should cause the highlight to pick up its global namespace attributes but need to re-test it)...Also need to permit some type of options in blocklist. I think both of these should be possible

[shyun3]

ok, thank you for looking into this!

[TaDaa]

I think after updating vimade it should work now! let me know if not though! Fixed an issue with how winhl was being prioritized. For the blocklist, you'll want these settings I think:

require('vimade').setup({
  recipe = {'default', {animate = false}},
  blocklist = {
    extra = {
      highlights = {
        'WinBarNC', '/DropBar.*/'
      }
    }
  }
})

[shyun3]

Yes, the inactive icons are grayed out now. It doesn't even look like the blocklist is needed anymore:

Thank you!