nvim-tree / nvim-tree.lua

A file explorer tree for neovim written in lua

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Showing some error messages on NvimTree Close

melsonic opened this issue · comments

Description

Some Error messages showing up when trying to close NvimTree when no file is opened

error_nvimtree

Neovim version

NVIM v0.8.2
Build type: Release
LuaJIT 2.1.0-beta3
Compiled by runner@fv-az190-151

Operating system and version

Ubuntu 22.04

nvim-tree version

215b29b

Minimal config

this is the nvim-tree configuration file

`
-- disable netrw at the very start of your init.lua (strongly advised)
vim.g.loaded_netrw = 1
vim.g.loaded_netrwPlugin = 1

-- set termguicolors to enable highlight groups
vim.opt.termguicolors = true

-- empty setup using defaults
require("nvim-tree").setup()

-- OR setup with some options
require("nvim-tree").setup({
	sort_by = "case_sensitive",
	view = {
		adaptive_size = true,
		mappings = {
			list = {
				{ key = "u", action = "dir_up" },
			},
		},
	},
	renderer = {
		group_empty = true,
	},
	filters = {
		dotfiles = false
	},
})
`

Steps to reproduce

  1. open neovim
  2. open NvimTree (make sure no file is opened)
  3. try to close NvimTree, then it will show some error messages

Expected behavior

No response

Actual behavior

No response

I was running this same NvimTree and Neovim version a few up until today and didn't ever have this issue.
I am on a mac though. But that being said, your screenshot is from your user setup and not the temp setup right?

Can you confirm that this still happens when running Neovim along with the minimal config?

@tjex Yes, the issue still persists, actually previously when I run nvim . it used to open the folders and files in that directory, but now it just opens a new empty file with the name .

Ok. Regarding nvim not opening by default when launching at a directory, I also made an issue about that #1965 , and was pointed to read #1669 , which outlines it is no longer a default function and needs to be addressed on a user by user basis.

Are you sure it's creating a file called '.' though?
You can test by writing something and then trying to save, you should get an error saying that it can't be saved because it's a directory. You can see a screenshot of this in my issue, here again #1965 .

But on the error on closing, I can't help much. Just trying to filter out options for the maintainer.

@tjex ok, #1965 is the issue I'm talking about, I wasn't updated about that default behavior, but now it makes the whole sense. As you suggested I tried to save the file, and it prints `E502: "." is a directory. Again thanks for your precious time.

The close failure is quite concerning; we are trying to close an apparently valid window.

Possibilities:

  • some autowrite functionality is attempting to write the nvim-tree buffer
  • another plugin or automation is intercepting the nvim_win_close events and introducing a problem

Confirming: are you running with an nvt-min.lua or with your full nvim setup?

For what is worth, I'm currently able to replicate this bug. In a fairly minimal setup (nvim-tree is the only plugin):
image

In my case, this was the culprit:

" View stuff.
augroup AutoSaveView
	au BufWinLeave ?* mkview
	au BufWinEnter ?* silent! loadview
augroup END

Removing this solved the issue.

Although I'm not sure why nvim-tree would fail in that case.

I can replicate this with those autocommands. I tried another arbitrarily selected plugin https://github.com/liuchengxu/vista.vim and it fails, differently.

:copen from an empty buffer will throw E788: Not allowed to edit another buffer now from the BufWinEnter au.

mkview failing seems reasonable, as there is no file name for the nvim-tree buffer.

I'm not sure what you're trying to do here; what is the purpose of those autocommands? With understanding we can resolve this.

Apparently, it's something to do with folds: https://stackoverflow.com/questions/2142402/code-folding-is-not-saved-in-my-vimrc
I've removed them though, and haven't missed them since :)

I'm not sure if it's reasonable to expect it to fail, or if this is something that should be fixed. Just decided to leave the reason for my (similar) issue here, as it may help OP to debug his.

No real issues for me though.

These autocommands need some filtering; they can't reasonably apply to all buffers i.e. not regular file buffers.

Closing this one as it is not nvim-tree specific.