Reactive with catpuccin preset results in permanently dimmed buffer when you create a new one.

[Michaelpalacce]

Here is a link to my dotfiles: https://github.com/Michaelpalacce/.dotfiles/blob/master/nvim/.config/nvim/lua/plugins/reactive.lua

I have confirmed the issue is with reactive, if I disable reactive I don't have this issue.

Furthermore the issue is with the cursorline preset.

https://github.com/catppuccin/nvim/commit/151e478edf8108cfd451a3cbd44d0a20503e7b42#diff-68c792bb5f250145916c09806fe2ef18bb663adbd3459f2ab4cb193690ef13be

from here

and a recording :

https://github.com/rasulomaroff/reactive.nvim/assets/17056014/0b0592c0-c177-4dbb-aea9-1ed03b1d31e7

[rasulomaroff]

Hi there @Michaelpalacce! Thank you for opening the issue, I'll try to investigate it You pointed that it only happens with the cursorline preset enabled and that means that the issue is somewhere in the winhighlight option.

The problem is that it's really hard to debug since a lot of plugins use vim.schedule method for a lot of things and the error could be either on my side or nvim-tree plugin that you're using. They also use the winhighlight option.

Will get back to you when I look at it

[rasulomaroff]

Hi again @Michaelpalacce! Prepare for the long-read :)

Overall, I spent the whole day investigating what's going on there and I'm a bit surprised.

Good news - it's not a reactive.nvim's bug nor it's a nvim-tree's bug Bad news - it seems like a Neovim bug or I don't even know whether it's a bug at all

How reactive.nvim works:

1. Set listeners to WinEnter, WinLeave, ModeChanged, BufWinEnter events.
2. Highlight whenever some of those listeners are triggered.

To make the process a bit easier let's imagine reactive only listens to WinEnter mode (because the bug occurs even if I disable all of those listeners except this one).

The algorithm is very simple:

1. WinEnter (or other event) is triggered
2. Get winhl option. Add reactive's highlights.
3. Include previous highlights as well (from other plugins, for example)
4. Set the updated winhl option (previous + reactive highlights).

But the surprising part here is that you'll get the same result (bug) even if you don't change winhl option, but still apply it.

For example, you can:

1. disable reactive
2. add this autocmd to Neovim initialization

vim.api.nvim_create_autocmd('WinEnter', {
  callback = function()
    local win = vim.api.nvim_get_current_win()
    vim.api.nvim_win_set_option(win, 'winhighlight', vim.api.nvim_win_get_option(win,'winhighlight'))
  end,
})

What it does is just applying the same winhl option that is already applied.

3. enter Neovim
4. open your nvim-tree by :NvimTreeOpen
5. close all other windows except nvim-tree by pressing <Ctrl-w> + o
6. open any file through nvim-tree file tree
7. observe the "bug" in the opened file haha

Even though you didn't change the winhl option itself, but you will still get this bug.

Another thing to know here is how nvim-tree opens a file in this case (I checked in their codebase):

1. It creates a split by executing :vsplit
2. Then it executes another command :edit yourfilename.ext

At this point I'm completely lost what to do next. Maybe the best solution is to ask Neovim team about this one. I think it's something in the winhl internals, but I don't really know, just guessing here.

I will not close this issue for now since I'm not completely sure about it, but again, I showed you the way you'll get the same bug even without using reactive at all.

Thank you for pointing this! Will be glad to continue this discussion.

Here are a video showing the way to get this error and a screenshot that proves that reactive is disabled.

https://github.com/rasulomaroff/reactive.nvim/assets/80093436/d6a3fc47-37d4-4adc-9f74-7def0d1ca403

[Michaelpalacce]

Hey @rasulomaroff,

Thank you for the great insight on this one!

Honestly I am not sure what to say either, it seems like you took quite a lot of time and effort into this one. I have to admit that this is really above what I understand when it comes to Neovim. I think it'd make sense to close this, leave it as history?

[rasulomaroff]

@Michaelpalacce I think I'm gonna look at their C code first (if I understand anything 😄) and maybe find the issue there. And then open this issue in their repo. Because as I said, I'm not very sure on what's exactly going on in this case, but it's definitely something weird, at least for me.