nvim-tree / nvim-tree/nvim-tree.lua
Falling to first folder on path, e.g: nvim project/packages/docs, shows docs first and when open a file falls to project.
Nobody has claimed this yet.
- Dominant language
- Lua
- Stars
- 8.6k
- Forks
- 639
- Avg merge
- 1d 14h
- Merged PRs (30d)
- 2
Description
Description
On 09/08 I opened an issue (#3180 ) about an error I was facing and it was solved simply by going back to commit "a9156c0" and the error was gone.
Today just noticed this new bug, is worth mentioning that I wasn't even using commit "a9156c0" before finding the bug from issue #3180.
Now when I do the following:
$ nvim arkos/packages/docs
It will open nvim and show nvim tree with docs files, but all of sudden when I try to open a file or folder it falls back to files from arkos folder.
I simply solved it by going back to a commit from 3 weeks ago, commit "543ed3c", and it is working fine as I used to work with it.
I saw Multi Instance refactor and I am interested into contributing but currently I am not that aligned to lua maybe by the time I finish grasping it the refactor is still up, I am currently working on nodejs framework for RESTful API built on top of express and prisma consider checking https://github.com/uanela/arkos.
Neovim version
NVIM v0.11.2
Build type: Release
LuaJIT 2.1.1748459687
Operating system and version
macOS Sequoia 15.4
Windows variant
No response
nvim-tree version
commit a9156c0 (have the problem), commit 543ed3c (solution so far).
Clean room replication
return {
"nvim-tree/nvim-tree.lua",
-- commit = "a9156c0",
commit = "543ed3c",
dependencies = { "DaikyXendo/nvim-material-icon" },
keys = {
{ "<leader>e", function() require('nvim-tree.api').tree.focus() end, desc = "Focus file explorer" },
{ "<C-b>", "<cmd>NvimTreeToggle<cr>", desc = "Toggle file explorer" },
},
config = function()
local tree_opened = false
require("nvim-tree").setup({
renderer = {
icons = {
webdev_colors = true,
},
group_empty = true,
},
sort_by = "case_sensitive",
view = {
width = 30,
side = "right"
},
filters = {
dotfiles = false,
},
update_focused_file = {
enable = true,
update_cwd = false,
update_root = false,
ignore_list = {},
},
on_attach = function(bufnr)
local api = require("nvim-tree.api")
if not tree_opened then
tree_opened = true
api.tree.change_root_to_node()
end
api.config.mappings.default_on_attach(bufnr)
vim.keymap.set('n', '<C-j>', function()
local node = api.tree.get_node_under_cursor()
if node.type == "file" then
local last_win = vim.fn.winnr('#')
if last_win > 0 and vim.api.nvim_win_is_valid(last_win) then
vim.cmd(last_win .. "wincmd w")
vim.cmd("edit " .. node.absolute_path)
else
api.node.open.edit()
end
end
end, { buffer = bufnr })
end,
})
end,
}
Steps to reproduce
- Simply configure your nvim with Lazy.nvim and the use the configuration above for your nvim-tree
- $ nvim some/nested/folder
Expected behavior
Should show the content of the latest file/folder on the path and keep it even though I interact with it except when I trigger to explore outer folders.
Actual behavior
Shows the content of the last file/folder on path but as soon as I interact with some file/folder on the tree it quickly shows the content of the first file/folder of the path.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the supplied Lazy.nvim configuration, especially update_focused_file and the custom api.tree.change_root_to_node and api.node.open.edit mappings. Reproduce with nvim some/nested/folder at the reported commits, then trace how interaction changes the tree root. Done means the initial nested folder remains selected while opening files or folders, unless the user explicitly explores an outer folder.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- lua, neovim
- Domain
- cli, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100