Closed Michaelpalacce closed 6 months ago
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
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:
WinEnter
, WinLeave
, ModeChanged
, BufWinEnter
events.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:
winhl
option. Add reactive's highlights.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:
reactive
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.
:NvimTreeOpen
nvim-tree
by pressing <Ctrl-w> + o
nvim-tree
file treeEven 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):
:vsplit
: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
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?
@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.
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