Highlights differ if window spans area with text

[gegoune]

Hey, I was noticing that sometimes I get dimmed notifications and finally caught the scenario when dimming happens.

Highlights will be dimmed if fidget's window is drawn over area with no text; that is not the case if there is text on lines underneath fidget's window.

Please see this quick screencast illustrating above:

highs.mov

Please note that dimming goes away even if I change buffer while previously dimmed text still persist on the screen, but underlying lines are filed with text.

Desired highlights are the brighter ones:

Tried with:

require('fidget').setup {
  window = {
    winblend = 100,
  },
}

as well as window.winblend = 0 - outcome is the same in both cases.

[xulongwu4]

I noticed that this doesn't happen when winblend is zero

[gegoune]

Can confirm. As you can see in my original report I mistakenly set window.winblend instead of window.blend which I believe was in readme/docs at the time.

[j-hui]

Yeah there was previously a typo in the docs, which has since been fixed.

Sorry I haven't had time to look into this yet, but ideally this shouldn't happen even with window.blend set to 100.

[lalitmee]

@j-hui, I am not sure if this is a related issue, but I am also facing something like this.

I have tried setting the highlights but that is only setting the highlight for the foreground, not the background.

[lalitmee]

In my config, I had Normal highlight guibg set to NONE.

Removed that and fixed.

[j-hui]

Seems to be fixable with some amount of config wrangling.

[gegoune]

Would you mind explaining what you have in mind? I am still seeing that issue with latest changes (great work btw! Thanks a bunch!)

[j-hui]

@gegoune Sure, what config and theme are you using at the moment?

[gegoune]

All defaults from fight.nvim, just calling setup(), colorscheme is zenbones.

[j-hui]

Ugh ok I had really not closely read the steps to reproduce from the original post, this is clearly still an issue.

[rtgiskard]

Ugh ok I had really not closely read the steps to reproduce from the original post, this is clearly still an issue.

I have just find the similar issue related to winblend:

The C source file end at line 37, the right bottom notifications are fidget progress messages from <C-f> format operation.
The color of popup progress message greatly inflected by the background context with winblend=100.

To reproduce, you may use this config, and edit some file like lua, then just press <C-f> repeated so that you get repeat progress message for the format operation.

[j-hui]

Yeah so this is something to do with the semantics of winblend. I looked into it at one point since re-opening this issue, but didn’t really conclude anything useful, though I suspect a fix will either have to come from (1) Neovim itself, or (2) switching to extmark-based rendering (which gives me more fine-grained control over which parts of the buffer are populated).

I wanted to wait until I’d experimented with (2) first before filing an issue upstream/haven’t had bandwidth to get around to it (I’m working on deduplication rn)

[baggiponte]

I had the same problem as @lalitmee. I am using gruvbox material with transparent background and I solved it by setting winblend to 0.