Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with open(path to directory) #3086

Open
jagerem opened this issue Mar 22, 2025 · 1 comment
Open

Problem with open(path to directory) #3086

jagerem opened this issue Mar 22, 2025 · 1 comment

Comments

@jagerem
Copy link

jagerem commented Mar 22, 2025

Description

Whenever using api.tree.open({path = full_path}) it have to be done twice until it works. And when is done and after that when move to the other directory - no matter if window with nvim-tree is closed or not - above command should be invoked twice until tree is opened in specified directory
-- But when I use command :NvimTreeClose | NvimTreeOpen path_to_directory it works fine.
:source /home/test/session.vim | NvimTreeClose | NvimTreeOpen path_to_directory -does not work either - means need to repeat this command twice and then it works - as a 3 steop described in "Steps to reproduce"
The problem exists when it is used together with session.

P.S. I use lazy nvim

Neovim version

NVIM v0.10.4
Build type: RelWithDebInfo
LuaJIT 2.1.1713484068
Run "nvim -V1 -v" for more info

Operating system and version

Linux Debian 12

Windows variant

No response

nvim-tree version

c09ff35

Clean room replication

Here is a simple code to help to understand a problem.
file name - test.lua
M = {}


M.restore_session = function (path_to_session)
    vim.api.nvim_command("source "..path_to_session)
end

M.load_dir = function ()
    local api = require('nvim-tree.api')
    local view = require('nvim-tree.view')
    if view.is_visible() then
        api.tree.close()
    end

    api.tree.open({path = "/home/test/"})

end

M.is_visible = function ()
    local view = require('nvim-tree.view')
    print("nvim-tree is visible ", view.is_visible())
end

M.get_buffers = function()
    local buffers = vim.api.nvim_list_bufs()
    for _,v in ipairs(buffers) do
        print("value --> ", v, "  |  buffer name --> ", vim.api.nvim_buf_get_name(v))
    end
    print("-----------------------------")
end
	vim.keymap.set("n", "<leader>ws", function() M.restore_session("/home/test/session.vim") end, { desc = "Restore session only" }) -- restore last workspace session for current directory
	vim.keymap.set("n", "<leader>wl", function() M.load_dir() end, { desc = "Open tree in specified directory only" }) -- restore last workspace session for current directory
	vim.keymap.set("n", "<leader>wa", function() M.restore_session("/home/test/session.vim") M.load_dir() end, { desc = "Restore session and open tree in specified directory" }) -- restore last workspace session for current directory
	vim.keymap.set("n", "<leader>wi", function() M.is_visible() end, { desc = "Check visibility of tree" }) -- restore last workspace session for current directory
	vim.keymap.set("n", "<leader>wb", function() M.get_buffers() end, { desc = "Get all buffers" }) -- restore last workspace session for current directory


return M



Steps to reproduce

session optians are set in options.lua ==> vim.o.sessionoptions="blank,buffers,curdir,folds,help,tabpages,winsize,winpos,terminal,localoptions"

  1. when first nvim is open and key map wa is used - it is working fine.
  2. then go in tree to different directory and place the cursor on any other buffer
  3. hit again wa - this is unwanted behaviour - because instead opening directory in the tree on /home/test the tree is opened in the new directory but when you hit wa again it goes to the /home/test as it should be.

Some notes:
When you at first restore session using ws you can see restored session with tree but there is an empty buffer - without any directories and in this occasion if wi is used you will see is_visible= false but if next you hit wb and :messages - it can be noticed there is a buffer with name NvimTree_1 - this is strange.

What is more when you separately restore session and then load directory - it is working fine.

Testing
I was testing this without any session manager or tab/buffer manager.
I am aware there is an instruction how to open tree within auto-session but again this solution opens tree but not specified directory when you use open("path")

For sure this issue is not big deal but just little bit irritating. And not sure if for 100% it relates to nvim-tree.

my tree settings:
return {
"nvim-tree/nvim-tree.lua",
dependencies = "nvim-tree/nvim-web-devicons",

config = function()
local nvimtree = require("nvim-tree")

nvimtree.setup({
  view = {
    width = 35,
    relativenumber = false,
  },
  -- change folder arrow icons
  renderer = {
    indent_markers = {
      enable = true,
    },
    icons = {
      glyphs = {
        folder = {
          arrow_closed = "", -- arrow when folder is closed
          arrow_open = "", -- arrow when folder is open
        },
      },
    },
  },
 
  -- disable window_picker for
  -- explorer to work well with
  -- window splits
  -- actions = {
    -- open_file = {
      -- window_picker = {
        -- enable = false,
      -- },
    -- },
  -- },
  filters = {
    custom = { ".DS_Store" },
    dotfiles = true,
   },
  git = {
    ignore = false,
  },
})

-- set keymaps
local keymap = vim.keymap -- for conciseness

keymap.set("n", "<leader>ee", "<cmd>NvimTreeToggle<CR>", { desc = "Toggle file explorer" }) -- toggle file explorer
keymap.set("n", "<leader>ef", "<cmd>NvimTreeFindFileToggle<CR>", { desc = "Toggle file explorer on current file" }) -- toggle file explorer on current file
keymap.set("n", "<leader>ec", "<cmd>NvimTreeCollapse<CR>", { desc = "Collapse file explorer" }) -- collapse file explorer
keymap.set("n", "<leader>er", "<cmd>NvimTreeRefresh<CR>", { desc = "Refresh file explorer" }) -- refresh file explorer

end
}

Expected behavior

Always open tree in the same place where session had been saved whenever session was restored.

Actual behavior

No response

@jagerem jagerem added the bug Something isn't working label Mar 22, 2025
@alex-courtis
Copy link
Member

Please provide a clean room replication as per the instructions.

Please provide steps to reproduce.

@gegoune gegoune removed the bug Something isn't working label Mar 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants