bug: Error when opening a new tab if Oil is currently open

[RoryNesbitt]

Did you check the docs and existing issues?

• I have read the docs
• I have searched the existing issues

Neovim version (nvim -v)

NVIM v0.8.2

Operating system/version

Endeavour OS

Describe the bug

If you're currently looking at an Oil buffer and you use the command tabedit or tabnew it pops up with an error Oil split could not find parent window. Please try to replicate whatever you just did and report a bug on github

So I'm doing that. Other than this displaying everything seems to work as expected

Steps To Reproduce

nvim .
:tabnew

Expected Behavior

Oil to not needlessly worry
Everything is fine, stress is bad for a young plugin, you're doing great <3

Directory structure

No response

Repro

-- save as repro.lua
-- run with nvim -u repro.lua
-- DO NOT change the paths
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "runtime", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({
    "git",
    "clone",
    "--filter=blob:none",
    "--single-branch",
    "https://github.com/folke/lazy.nvim.git",
    lazypath,
  })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  "folke/tokyonight.nvim",
  {
        "stevearc/oil.nvim",
        config = function()
            require("oil").setup({
              -- add any needed settings here
            })
        end,
  },
  -- add any other plugins here
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here

Did you check the bug with a clean config?

• I have confirmed that the bug reproduces with nvim -u repro.lua using the repro.lua file above.

[stevearc]

Thanks for the report, and the kind words! This actually was causing a bug, just subtly. It was interfering with resetting the window options after leaving an oil buffer after you :tabnew. Should be fixed now!

[RoryNesbitt]

This now gives a more classic error when the new buffer AND the current buffer is the pwd.

nvim .
:tabnew .

Error executing vim.schedule lua callback: /home/rory/.local/share/nvim/lazy/oil.nvim/l
ua/oil/util.lua:130: Invalid buffer id: 5
stack traceback:
        [C]: in function '__index'
        /home/rory/.local/share/nvim/lazy/oil.nvim/lua/oil/util.lua:130: in function </
home/rory/.local/share/nvim/lazy/oil.nvim/lua/oil/util.lua:121>

Also interesting notes:

• While this error is on screen I see netrw behind it, when I hit enter to close it I get oil and it appears to work great.
• This does not happen if you open a different directory e.g. :tabnew lua
• if you open a directory in the current oil, then you tabnew the same one you just opened you get no error but you get netrw not oil. e.g. cd .config/nvim; nvim . select lua and enter :tabnew lua

[stevearc]

Ah, it's more race conditions. There's more edge cases around the netrw conflicts than I thought :/

The first part of this is fixed. Still working on that last one.

[stevearc]

Well I've wrestled with it for a while now, but I've hit a case that I can't figure out how to handle gracefully. It's triggered by nvim lua then :e lua. The issue is that we try to rename the buffer to the oil:// format, but that buffer already exists. We then fall back to creating a new buffer and replacing the existing one, but somehow in the meantime netrw manages to delete the old buffer and replace it with a new one, so our replace operation fails. I've tried finding a way to stop netrw (not possible; all the variables that affect the control flow are script-local), changing the timing of the replace operation (doesn't help), and detecting the new buffer creation (strangely, I seem to not get any autocmds for the new buffer. No BufNew, BufAdd, BufEnter, nothing. Even with nested = true). I'm documenting this in case I try to pick this back up again some time down the road, but I'm giving up for now. I think that I'm okay with saying that if you don't disable netrw, you may sometimes see netrw. As a compromise, I've added a notification that tells the user how to disable netrw.

[RoryNesbitt]

Yeah that sounds like a fair solution. In practice now I see netrw for just a split second once per session, and the cursor position changes in the new tab. Both things being pretty non-issues considering how rare this actually comes up in real use