bug: Oil buffer takes time to close after opening a file

[fiplox]

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

ArchLinux

Describe the bug

I'm using buffer manager and if I open a file with Oil and open buffer manager menu, Oil buffer still appears in the list of buffers. But, if I wait about 5-10 seconds, Oil buffer closes itself (expected behavior).
Buffer manager shortens the path to a file, but oil buffer uses, if I understand correctly, a protocol oil:///<path/to/a/file>. And when I trigger buffer manager, it shortens oil buffer removing one slash, triggering second time will remove another slash which basically gives a buffer that does not exist.
While it is probably a bug from a buffer manager side to shorten path to protocols, the oil's problem is not closing the buffer immediately after opening a file.

Steps To Reproduce

1. nvim -u repro.lua file
2. :Oil
3. Open any file
4. :lua require("buffer_manager.ui").toggle_quick_menu() -> buffer in the list

Expected Behavior

The oil buffer closes right after opening a file.

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
	{ 'j-morano/buffer_manager.nvim', dependencies = { 'nvim-lua/plenary.nvim' } },
}
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]

Let me first explain what's happening, and why it's happening.
I've set an autocmd to run on BufHidden that will, after a delay of 2 seconds, delete any unmodified oil buffers that are not visible. The reason for this is that every time you enter a new directory, you create a new oil:// buffer. So if you're editing foo/bar/baz.txt, then hit - twice to go up to the root directory, you'll have the following buffers open:

• oil:///path/to/cwd/foo/bar/
• oil:///path/to/cwd/foo/
• oil:///path/to/cwd/

I figured that most people probably don't want to have to clean these all up manually, and also don't want them sticking around, which is why I opted to do this auto-cleanup logic.

What does your workflow look like, that you want to switch back to oil using buffer navigation? For me, I'm typically only using oil when it's visible. If I understand how you're using it, I might be able to offer you a better solution than just "you have to manually dispose all of the oil buffers now," though that is also an option if it's what you want.

[fiplox]

That explains what I'm seeing and really makes sens. The only thing that bugs me a little is the delay in cleaning of 2 seconds.
On my use case, when I open a file, I sometimes immediately (in span of 2 seconds) open buffer manager to switch to another buffer, and I prefer not having oil in there when I'm done browsing.
Just tested your exemple, and indeed, it creates two buffers, then if I return to the foo/bar it leaves me with one buffer immediately.

Is there a reason for having 2 second delay in cleaning up? And also why not reuse the same buffer, instead if creating new ones on each directory change?

Anyways, nothing critical, I love your plugin!

[stevearc]

The 2 second delay is both a small optimization (if you return to that directory in the next 2 seconds, which is not unlikely, we don't have to rebuild the whole thing) and prevents unexpected behavior when interacting with other plugins. Sometimes plugins have to do a bunch of window/buffer switching all at once so quickly that it's invisible to the user, but that might still trigger a BufHidden event. This delay makes sure that the buffer is actually not visible to the user anymore by giving it some time to settle. Is 2 seconds the right number? Not sure. Opinions on that are welcome.

We can't re-use the same buffer because of how oil works, unfortunately. We have to keep every directory completely isolated so that we can track the edits independently.

I mentioned in #28 that setting buflisted = false will prevent this sort of UI-flicker. Based on the fact that this has come up twice now, and that setting buflisted = true is generally only useful if you want to switch to a buffer after it's hidden, I think I'm going to just make this the default.

[fiplox]

That actually works really well with buflisted = false on my use case. Thank you to pointing out. Closing the issue