Opening nvim-tree in a split breaks vinegar-style

[sstallion]

Description

I've been scratching my head over this one this evening. I've been experimenting with using nvim-tree in vinegar mode and for the most part everything works as expected, however attempting to open nvim-tree from within a split breaks terribly. This can most easily be seen by editing a directory (eg. :e .) from within a split. The result is the split is closed, and the nvim-tree window is opened in a vertical split rather than replacing the buffer as expected.

Neovim version

NVIM v0.9.0
Build type: Release
LuaJIT 2.1.0-beta3

Operating system and version

macOS 12.5

nvim-tree version

b1e074d

Minimal config

call plug#begin()
Plug 'nvim-tree/nvim-tree.lua'
Plug 'nvim-tree/nvim-web-devicons'
call plug#end()

lua <<END
local api = require('nvim-tree.api')

require("nvim-tree").setup {
  disable_netrw = true,
  on_attach = function(bufnr)
    local function opts(desc)
      return {desc = 'nvim-tree: ' .. desc, buffer = bufnr, noremap = true, silent = true, nowait = true}
    end
    vim.keymap.set('n', '<CR>', api.node.open.replace_tree_buffer, opts('Open: In Place'))
  end
}
END

### Steps to reproduce

1. `nvim`
2. `:split`
3. `:e .`

### Expected behavior

The nvim-tree window replaces the split buffer.

### Actual behavior

The nvim-tree window closes the split buffer and opens a vertical split for the tree.

[alex-courtis]

Replicated with defaults. Nothing specific to vinegar style.

It's working as intended: the tree will open on the left/right depending on view.side.

You can, however, override this behaviour using the newly added winid parameter for :help nvim-tree-api.tree.open(), toggle and find_file.

Try something like this:

require("nvim-tree.api").tree.open({ winid = vim.api.nvim_get_current_win() })

[alex-courtis]

We need some recipes for winid...

[sstallion]

Interesting, I'll give that a shot. I was also able to work around this issue by setting hijack_directories = {enable = false} and adding the following autocommand:

vim.api.nvim_create_autocmd({"BufEnter", "BufNewFile"}, {callback = function()
  local buf = vim.api.nvim_get_current_buf()
  local bufname = vim.api.nvim_buf_get_name(buf)
  if vim.fn.isdirectory(bufname) ~= 1 then
    return
  end
  lib.open {current_window = true, path = bufname}
end})

[sstallion]

It's working as intended: the tree will open on the left/right depending on view.side.

I've spent a bit of time looking at this today and I'm not sure I agree with this being correct behavior. Looking through view.lua there seems to be a number of baked in assumptions that a given tab can only contain one NvimTree_* buffer. This limitation is fundamentally incompatible with vinegar style where navigation is normally isolated between buffers. Using netrw as an example, you can create as many splits as you wish and navigate independently in each one.

To better understand what I'm talking about, try running the following commands with the default configuration:

:e .
:split /

The original buffer opened with :e . is immediately closed and replaced with :split /. Try this again with directory hijacking disabled and netrw enabled and you can see the difference.

I played around a little with loosening the above restriction, but it turned into a mess quickly. This is probably beyond my ability to fix in the time I have. I have a fairly close analogue to vinegar behavior at the moment provided I do not attempt to open more than one NvimTree_* buffer in a given tab. As much as it pains me, I may have to re-enable netrw for directory browsing - the one buffer per tab restriction might be difficult to follow.

[alex-courtis]

baked in assumptions

That is correct. nvim-tree does not properly handle multiple instances across tabs and the state of the tree is a singleton.

There is much work to be done to isolate instances. See #457

Assistance implementing such features would be gratefully appreciated.

Closing as this is not a bug and tracked elsewhere.

[alex-courtis]

Tracking at

• Multi Instance - Contributors Wanted - Please Take An Issue #2255