nvim-tree / nvim-tree/nvim-tree.lua

nvim-tree.lua destroys split pattern, and now show the opened buffer

Open
#3,083 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug reproduced
Dominant language
Lua
Stars
8.6k
Forks
639
Avg merge
1d 14h
Merged PRs (30d)
2

Description

Description

When I open nvim and split, and then toggle with current_window=true, and then open a new file from nvim-tree. The split pattern is destroyed, and the opened new file is not on the top.

Neovim version
NVIM v0.10.4
Build type: Release
LuaJIT 2.1.1713484068
Run "nvim -V1 -v" for more info
Operating system and version

Linux WorkStation 6.11.0-19-generic #19~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Feb 17 11:51:52 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

Windows variant

No response

nvim-tree version

head

Clean room replication
This is my init.lua:

-- download and install and load plugins --
-- install lazy.vim if it does not exist
local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not (vim.uv or vim.loop).fs_stat(lazypath) then
  vim.fn.system({
    "git",
    "clone",
    "--filter=blob:none",
    "https://github.com/folke/lazy.nvim.git",
    "--branch=stable", -- latest stable release
    lazypath,
  })
end
vim.opt.rtp:prepend(lazypath)

-- install plugins
require("lazy").setup({
    {
        "nvim-tree/nvim-tree.lua",
        version = "*",
        lazy = false,
        dependencies = {
            "nvim-tree/nvim-web-devicons",
        },
    },
})

local nvim_tree_api = require("nvim-tree.api")
require('nvim-tree').setup({
    update_focused_file = {
        enable = true,
    },
    actions = {
        open_file = {
            quit_on_open = true,
            window_picker = {enable = false},
        }
    },
   git = {enable = false},
})


-----------------
-- key bindings --
-----------------
-- set <leader>
vim.g.mapleader = ","

vim.keymap.set('n', '<leader>o', ':only<cr>', opts)
vim.keymap.set('i', '<C-x>', '<esc>', opts)
vim.keymap.set('n', '<leader><cr>', ':noh<cr>', opts)
vim.keymap.set('n', 'ss', ':set spell!<cr>', opts)


-- Hint: see `:h vim.map.set()`
-- Better window navigation
vim.keymap.set('n', '<C-h>', '<C-w>h', opts)
vim.keymap.set('n', '<C-j>', '<C-w>j', opts)
vim.keymap.set('n', '<C-k>', '<C-w>k', opts)
vim.keymap.set('n', '<C-l>', '<C-w>l', opts)

-- Resize with arrows
vim.keymap.set('n', '<C-Up>', ':resize -2<CR>', opts)
vim.keymap.set('n', '<C-Down>', ':resize +2<CR>', opts)
vim.keymap.set('n', '<C-Left>', ':vertical resize -2<CR>', opts)
vim.keymap.set('n', '<C-Right>', ':vertical resize +2<CR>', opts)

-- nvim-tree shortcuts
vim.keymap.set("n", "<leader>n",
    function()
        nvim_tree_api.tree.toggle({
            path = "<args>", current_window = true,
            focus = true, find_file = false, update_root = false })
    end,
    { noremap = true })
Steps to reproduce
  1. $ nvim -u init.lua a b
  2. run :vs, here it should be like [a | b]
  3. n
  4. choose a file(such as a "c"), and press enter
Expected behavior

The split pattern should keep, and the new opened file should be in the split where nvim-tree is toggled. Here it is [c | b]

Actual behavior

The split pattern is gone, that is only a [a] is here. And the new opened file of "c" is not on top of the shown buffers.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the supplied init.lua and reproduce the issue using nvim -u init.lua a b, :vs, and the <leader>n mapping with current_window=true. Compare the resulting windows and buffer order with the expected [c | b] layout; done means the split is preserved and the selected file opens in the toggled window.

Written by the indexing model from the issue text.

Assessment

Tech stack
lua
Domain
tooling
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.