Issue: Statusline doesn't react to blocklist
Hi! I reallly love Your plugin, it solves most of my issues with windows dimming.
However I encountered an issue where the plugin lowkey doesn't react to excluding a highlight group it in config.
What I want to achieve is the following: I want the bottom status line (the one with a file name [in this case it's README.md]) to stay transparent:
However Your plugin makes it somewhat dark(ish):
How can I change it? I tried this config:
return {
"tadaa/vimade",
opts = {
recipe = { "default", { animate = true } },
fadelevel = 0.65,
tint = {
fg = { rgb = { 120, 120, 120 }, intensity = 1 }, -- all text will be gray
},
blocklist = {
default = {
highlights = {
-- Prevent ActiveTabs from highlighting.
"TabLineSel",
-- Exact highlight names are supported:
"WinSeparator",
-- Lua patterns are supported, just put the text between / symbols:
"/^SignColumn.*/",
"/^StatusLine.*/",
"LuaLine",
"/^LuaLine.*/",
},
buf_opts = { buftype = { "prompt" } },
-- buf_name = {'name1','name2', name3'},
-- buf_vars = { variable = {'match1', 'match2'} },
-- win_opts = { option = {'match1', 'match2' } },
-- win_vars = { variable = {'match1', 'match2'} },
-- win_type = {'name1','name2', name3'},
-- win_config = { variable = {'match1', 'match2'} },
},
},
},
}
But the line persists dark. Any ideas what can I do?
Thanks for filing @nxtkofi !
I assume this happens with just Vimade, colorscheme, and Lualine enabled ( based on the config above, but lmk if that's not the case)? If so, would you mind including a repro config (either minimal or dotfiles on github would be fine) - happy to take a look.
oh maybe just the output of hi StatusLine and hi StatusLineNC might be enough to see what is happening?
Guessing here, but they may link to another highlight group. I think blocklist highlights is kind of imperfect atm in that regard, although could probably just have it treated as an unlink.
When you have a chance, would you mind seeing if that fixes it for you. That should remove the imperfection between blocked highlights linking to unblocked ones. If not, I'll probably need a minimal repro config
Thanks for answering! Unfortunately that didn't fix it for me. Output of hi StatusLine and hi StatusLineNC is as expected. You can see my config here
I forgot to mention the most important part: The status line I'm referring to is in the other window. The main window is working as expected - pure lualine there. But the window that is dimmed has this weird dark line
Ah ok thanks:
I presume for the strange dark line, you mean the ~ symbol right? That is from the EndOfBuffer highlight, which should just need to be added into blocklist. It's basically a bad interplay between tint.fg and the fact that fg is what drives that particular symbol's color. I think the behavior is WAI though because it would be too difficult to determine the right thing to do (if a user wants to manipulate that color, it should work as well).
For the StatusLine -- blocklist is case-sensitive. The case-sensitivity could use a fix; I don't think Vim treats colors as case-sensitive names. Lualine appears to override the inactive colors for StatusLines, so the blocked highlight has to be formatted as below. If you don't always use Lualine, then you will also want to add StatusLineNC:
return {{
"tadaa/vimade",
opts = {
recipe = { "default", { animate = true } },
fadelevel = 0.65,
enabled = false,
tint = {
fg = { rgb = { 120, 120, 120 }, intensity = 1 }, -- all text will be gray
},
blocklist = {
custom = {
highlights = {
"WinSeparator", -- Note: unrelated in case you don't need this
"/^SignColumn.*/", -- Note: unrelated in case you don't need this
"EndOfBuffer",
"/^lualine.*/",
},
},
},
},
}}
Yes! It worked! It was the EndOfBuffer. I thought it's name is StatusLine... This is like 100th time I got something wrong because of the highlight group names.. How do You know the names for particular things in neovim? I always struggle to find them
Ok great!
Learned that one from Vim many years ago:D Think it was one of the first things that annoyed me about OOB config and NEEDED to change it, so I've never have forgotten the trauma, which is now shared with you:). There is more info here in case you are interested about the built-in groups :h highlight-default.
I think for this bug, let's keep it open and I'll get the case-sensitivity fixed relatively soon. EndOfBuffer could probably use some more thought as well just in case there is an intuitive behavior to put in place (i.e. maybe prevent fg tint if fg==Normal[NC].bg or something like that)