Tree does not refresh after :bdelete.
andychess opened this issue · 5 comments
Description
I like to work with the tree open all the time and with the root set to my desired folder. This all works fine. The only problem I have is when I close a buffer. I noticed that in this case, the tree does not update to match the file displayed, which is a little irritating.
Initially, I tried using a function to call :Bdelete and then :NvimTreeRefresh but this does not work. The tree shown matches the deleted file and not the one subsequently displayed in the buffer. Manually entering NvimTreeRefresh, or toggling the display, both correct the problem.
Bdelete is from a plugin and so I tried with :bdelete, followed by closing and opening nvim-tree. This works as individual commands, but not as a function.
Also, chaining the commands as :bd | NvimTreeClose | NvimTreeOpen doesn't work. The tree is again stuck on the path of the deleted buffer. Issuing the commands one at a time results in the correct path being displayed.
As a temporary workaround, I have a function that calls :Bdelete and then :NvimTreeClose. If I then manually open nvim-tree, the tree is shown correctly. This is the least worst option compared to manually refreshing the tree after closing the buffer, which feels very inelegant.
Neovim version
NVIM v0.10.4
Build type: Release
LuaJIT 2.1.1736781742
Operating system and version
macOS 15.3.1
Windows variant
No response
nvim-tree version
Clean room replication
vim.g.loaded_netrw = 1
vim.g.loaded_netrwPlugin = 1
vim.cmd([[set runtimepath=$VIMRUNTIME]])
vim.cmd([[set packpath=/tmp/nvt-min/site]])
local package_root = "/tmp/nvt-min/site/pack"
local install_path = package_root .. "/packer/start/packer.nvim"
local function load_plugins()
require("packer").startup({
{
"wbthomason/packer.nvim",
"nvim-tree/nvim-tree.lua",
"nvim-tree/nvim-web-devicons",
-- ADD PLUGINS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
},
config = {
package_root = package_root,
compile_path = install_path .. "/plugin/packer_compiled.lua",
display = { non_interactive = true },
},
})
end
if vim.fn.isdirectory(install_path) == 0 then
print("Installing nvim-tree and dependencies.")
vim.fn.system({ "git", "clone", "--depth=1", "https://github.com/wbthomason/packer.nvim", install_path })
end
load_plugins()
require("packer").sync()
vim.cmd([[autocmd User PackerComplete ++once echo "Ready!" | lua setup()]])
vim.opt.termguicolors = true
vim.opt.cursorline = true
-- MODIFY NVIM-TREE SETTINGS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
_G.setup = function()
require("nvim-tree").setup({
-- on_attach = on_attach,
hijack_cursor = true,
respect_buf_cwd = true,
sync_root_with_cwd = true,
auto_reload_on_write = true,
reload_on_bufenter = true,
filters = {
custom = { ".DS_Store" },
dotfiles = true,
},
update_focused_file = {
enable = true,
update_cwd = true,
},
renderer = {
root_folder_modifier = ":t",
icons = {
glyphs = {
default = "",
symlink = "",
folder = {
arrow_open = "",
arrow_closed = "",
default = "",
open = "",
empty = "",
empty_open = "",
symlink = "",
symlink_open = "",
},
git = {
unstaged = "",
staged = "S",
unmerged = "",
renamed = "➜",
untracked = "U",
deleted = "",
ignored = "◌",
},
},
},
},
diagnostics = {
enable = true,
show_on_dirs = true,
icons = {
hint = "",
info = "",
warning = "",
error = "",
},
},
view = {
width = 45,
side = "left",
},
})
end
-- UNCOMMENT this block for diagnostics issues, substituting pattern and cmd as appropriate.
-- Requires diagnostics.enable = true in setup.
--[[
vim.api.nvim_create_autocmd("FileType", {
pattern = "lua",
callback = function()
vim.lsp.start {
name = "my-luals",
cmd = { "lua-language-server" },
root_dir = vim.loop.cwd(),
}
end,
})
]]Steps to reproduce
- nvim -nu /tmp/nnt-min.lua
- NvimTreeOpen
- Open several files using C-]
- Observe that tree updates to the folder of the opened file.
- Scroll through open files using :bprev / :bnext. Tree updates as expected.
- Close one file using :bdelete.
- Observe that tree DOES NOT UPDATE TO SHOW DIRECTORY OF DISPLAYED FILE.
- NvimTreeRefresh displays the correct path.
- Any attempt to automate the refresh using a command or chaining :bdelete | NvimTreeRefresh does not work.
Expected behavior
When issuing :bdelete, tree updates to cwd of displayed file.
Actual behavior
Tree remains on cwd of file closed. This usually does not match the file displayed.
I'm not able to reproduce this; the window is closed on :bdelete. I don't think I'm following the steps correctly, see video.
The three files in the video are all in the same folder and so nothing changes after :bdelete. Please try opening three files from different folders (entering the folders with C-]). The correct tree should (and does) display after :bprev / :bnext, but after :bdelete, the tree remains in the folder of the deleted file.
Sorry, I'm still not understanding how this is reproduced; when I enter the folder <C-]> and move to the file's window, the tree will (correctly) refresh back at the root and highlight the file. I am clearly doing this wrong.
It looks like you're not using the minimal configuration in your video. It's also not clear what the directory structure is; are their two mains?
Please provide an exact reproducer with the minimal config above, showing the directory/file structure first e.g.:
$ find .
.
./1
./1/bar
./nvt-min.lua
./3
./3/foo
./2
./2/baz
$ nvim -nu nvt-min.lua:NvimTreeOpen- navigate to directory
1 - change to directory
1<C-]> - open file
bar<CR> - navigate back to the tree
<C-w><C-h> - navigate to . . . .
- . . .
- . . .
- observe tree at X not Y
Strangely, I can recreate the problem in the minimal config with my own file structure, but when I created a simple test directory (test) with three folders (1, 2, 3) each containing a single file (foo, bar, baz), then scrolling between them using :bnext didn't display the folder and file, but just displayed the full tree from test.
Anyway, don't worry. My question was really about the fact that I was unable to chain the commands (:bd | NvimTreeClose | NvimTreeOpen) but could issue the commands individually. I don't want to waste any more time on the issue, so thanks for looking at it.
I'm happy to attempt to replicate with your file structure; it sounds like there is a real issue here.
Please don't hesitate to reopen if this becomes a problem in the future.