nvim-tree.lua icon indicating copy to clipboard operation
nvim-tree.lua copied to clipboard

Allow opening the tree just like NERDTree in the current window or new splits when opening directories

Open kmoschcau opened this issue 2 years ago • 8 comments

Is your feature request related to a problem? Please describe. There are two situations:

  1. I have some split windows open, I'd like to open the tree in the window I am currently in with :edit .. What then happens is that the current window is closed and the tree buffer is opened in a side bar window.
  2. I want to open the tree in a new split with :vsplit . or :split .. Here no new window is created, the tree buffer is just opened in a new side bar window.

(I also just remembered that I also like to use :tabedit . and expect the tree buffer to open in a new tab, but I haven't tested what nvim-tree does in that case before I uninstalled it again.)

Describe the solution you'd like

  1. The tree buffer should open in the current window, hiding the buffer that was there before.
  2. The tree buffer should open in the new split window.

Describe alternatives you've considered Sticking with NERDTree.

Additional context nvim-tree already has the ability to replace its own buffer in a window with the buffer of a file I want to open. That's already half of my desired workflow. If I could now also just open the tree buffer in the window I want to open a new file in, with the built-in open commends, that would be a lot better than having to add multiple custom keymaps.

Also I checked this just now: This should work even if I open multiple windows with the tree buffer at the same time. The same buffer with the same state could be used in all windows. NERDTree does the same and it was never a problem, nor was there any need for me to have multiple tree states.

kmoschcau avatar Jul 24 '22 08:07 kmoschcau

2. I want to open the tree in a new split with :vsplit . or :split .. Here no new window is created, the tree buffer is just opened in a new side bar window.

:vsplit . and :split . opens the tree in a new vertical split with configured width. See :help nvim-tree.view.width. Only vertical split is currently supported. What is a side bar window?

  1. I have some split windows open, I'd like to open the tree in the window I am currently in with :edit .. What then happens is that the current window is closed and the tree buffer is opened in a side bar window.

nvim-tree will be opened in the current window. nvim-tree only supports vertical split windows. That window will be "changed" to a vertical split.

It appears that nvim-tree is achieving all the functionality you desire except:

  • horizontal split: this is conceptually problematic and unlikely to be implemented soon

Also I checked this just now: This should work even if I open multiple windows with the tree buffer at the same time. The same buffer with the same state could be used in all windows.

I'm not sure what you are looking for here. Are you looking to open multiple nvim-tree windows showing the same nvim-tree buffer in the same tab? That use case does not appear useful.

alex-courtis avatar Jul 25 '22 01:07 alex-courtis

Hi, the "side bar window" is just the term I use for the way nvim-tree always opens a new window on the leftmost edge of nvim with a fixed width. (With the default config, the things documented under nvim-tree-vimegar did not help here.)

The way I see it nvim-tree offers two currently conjoined features that I would like to be able to access separately:

  • the file browser buffer and the actions I can do in it
  • a functionality to toggle this "side bar window" and handling giving it focus and jumping back to a different window

I only want the first and don't need the latter. It would be great if nvim-tree could just leave the window management to nvim and only do its thing in its own buffer (and the file system of course). I just want to opt out of the extra window management feature.

To reproduce the :edit . scenario:

  • have two vertically split windows (one left, one right)
  • the right window has focus
  • if you now run :e., the right window is closed and nvim-tree is opened to the left of the previously left window

The expectation here would have been that nvim-tree opens in place of the buffer of the right window (the one with focus) and does not do any window management at all beyond that.

To reproduce the :vsplit . scenario:

  • have 'splitright' set
  • start nvim
  • run :vs.
  • nvim-tree again opens to the left of the current window

The expectation here would have been that a new window is opened to the right of the default window and nvim-tree is opened in it.

The :split . scenario is similar, just that the expectation is that nvim tree would open above or below (depending on 'splitbelow') the default buffer.

If you still need more info, I can try and record an asciinema later or find where I originally found this workflow to make it more clear.

Edit: As for having multiple tree buffers open at the same time: I only meant to not worry about that scenario and not add any extra handling for it.

Though now I have come to realize that NERDTree does actually keep multiple states: one for per opened root directory I believe. But that isn't really a concern for this issue and should be treated separately.

kmoschcau avatar Jul 25 '22 05:07 kmoschcau

In these scenarios, nvim-tree is working as intended: obeying the width and side settings. It's clear that doesn't meet your requirements.

You should be able to achieve "no window management" for opening the tree in the current window via .open_replacing_current_buffer() as per the vinegar section in the help. Did that work for you? What was the issue?

Similarly, edit_in_place should allow you to open the file in the current window.

This does not help you with the :edit . :vsplit . cases as nvim-tree will position the window. You could achieve this functionality with, say, a mapping:

  • :split
  • require"nvim-tree".open_replacing_current_buffer()

nvim-tree is focussed around "side bar window". Enhancements via an additional option to always use the current window may be possible.

alex-courtis avatar Jul 25 '22 06:07 alex-courtis

Hi, yes that does work, it however requires me to add additional bindings or commands for all of these situations. And that is just something I didn't want to do.

kmoschcau avatar Jul 25 '22 09:07 kmoschcau

I think @alex-courtis that there is a missing thing from this. After exploring a bit i've noticed that hijacking a directory buffer indeed replaces the window on the side it was specified. We might need to only hijack the current buffer, without replacing the tree in this case. I'm not too sure how we should implement this though.

kyazdani42 avatar Jul 26 '22 09:07 kyazdani42

Just my thumbs up for a feature like this. I switched from NerdTree for this plugin, but I would love to use my previous workflow with :e . or :vs /path/to/dir and have nvim-tree open as if it was another file being open.

ned-si avatar Aug 02 '22 09:08 ned-si

you could give it a try if you wish :) It probably wont be done soon since i will be afk for this month.

kyazdani42 avatar Aug 02 '22 11:08 kyazdani42

It would be my pleasure, but I unfortunately don't have the capability to help here.

I really love the integration with git and diagnostics and I'll keep using this plugin anyway :) I created a remap for the moment that - almost - makes it work the way imagine.

ned-si avatar Aug 08 '22 07:08 ned-si

As a person that is migrating from NERDTree too, I second this. The temporary fix (hijack_netrw = false) is incomparable with nvim-tree.lua experience.

naquad avatar Nov 03 '22 01:11 naquad

This is already implemented i believe. using hijack_directories and nvim-tree-vinegar. Closing since it seems multiple tree states is not in the near roadmap.

kyazdani42 avatar Nov 03 '22 15:11 kyazdani42

Tracking at

  • #2255

alex-courtis avatar Jun 04 '23 02:06 alex-courtis