After closing the diffview tab, sometimes some buffers retain the scrollbind/cursorbind settings

[yorickpeterse]

Sometimes when I close the tab opened by :DiffviewOpen, some of the buffers I've reviewed appear to still have scrollbind and cursorbind set. The result is that if you split the window and scroll there, it also applies to the previous window. To fix this I then have to run set noscrollbind and set nocursorbind in the appropriate windows.

The most frustrating part is that it seems to not always happen, and when it does it's not clear what might've caused it, making it really tricky to reproduce. As I've been experiencing this issue for a while now I've decided to create this issue regardless, hoping that somebody might be able to shed some light on this. In the mean time I'll try to figure out how to reproduce this issue.

[sindrets]

Window-local options have caused me a lot of pain in the past, because there are several aspects of these options that are not documented anywhere, and you just have to figure it out. I've seen core devs comment, saying they have had to change their own mental model of how window local options work several times.

Here are some notable pointers:

• The way you set local options is going to be extremely important in terms of how the editor is going to behave.
• Some methods of setting window local options will make them inheritable traits. This means any window created from the current window will inherit all those options. And this cascades. Windows created from the newly created window will also inherit those traits. This causes all sorts unexpected problems when you have unintentionally set an option this way.
  • Methods of setting local options that will make them inheritable are:
    • :set {local_option}[=value]
    • vim.opt.{local_option} = {value}
    • vim.api.nvim_win_set_option({winid}, {local_option}, {value})
  • Methods of setting local options that will not make them inheritable are:
    • :setlocal {local_option}[=value]
    • vim.opt_local.{local_option} = {value}
    • vim.api.nvim_set_option_value({local_option}, {value}, { scope = "local", win = {winid} })
    • When you mean to only set an option for the current window / buffer, always use these methods.

I'm acutely aware of the problems that can be caused by local options when mismanaged, and thus this plugin takes considerable care to restore any local options that it changes, both when leaving a view's tab page, and when closing a view.

I highly suspect that the times you have experienced this issue, that either you or a plugin you are using has incorrectly set an inheritable local value, thus creating a cascading problem.

[yorickpeterse]

@sindrets I doubt this is an issue with any plugins that I'm using. The only plugin I'm using that mentions cursorbind is diffview. The only plugins using scrollbind are diffview, and Telescope, the latter only seems to use this option for its results window. The only plugin that sets diff (which I think sets these bind options), is again diffview.

With that said, I can sometimes reproduce this issue by essentially doing the following:

1. Open a diffview tab and navigate to a file
2. Open that same buffer/file in another tab
3. Close the diffview tab
4. The scroll/cursor bind settings remain active in the buffer from step 2

Oddly enough this doesn't always reproduce it, and sometimes it also happens if the buffer from step 2 was opened before the diffview tab. I'll see if I can reproduce this issue more consistently.

[yorickpeterse]

I managed to reproduce it consistently as follows:

1. Open a project with changes in at least two different files
2. Run DiffviewOpen, it should make the first file active
3. Make the second file active using the sidebar or a shortcut
4. Make the first file active again
5. Navigate back to the first tab created from step 1
6. Open the first file in a buffer
7. The diffview settings now apply to this window as well, even after closing diffview

Here's what that looks like:

To rule out any of the plugins I mentioned above, I disabled all but a few crucial ones (e.g. plenary, diffview itself, and my colorscheme). In this case the problem still persists, further suggesting this isn't an issue with a third-party plugin.

[briandipalma]

I'm seeing this occasionally while using:

diff_buf_read = function(bufnr)
  -- Change local options in diff buffers
  local winid = vim.fn.bufwinid(bufnr)

  vim.api.nvim_set_option_value("relativenumber", false, { scope = "local", win = winid })
end,

Open neovim, check current edited files, open one and then I have no relative numbers. I would consider it a neovim bug though. I've added

view_leave = function()
  -- Reset options
  vim.opt.relativenumber = true
end,

to see if it fixes the issue.

[MaxKiv]

I have occasionally run into the same issue @yorickpeterse describes. It can be quite annoying