[NvimTree] nim-tree.lua setup called multiple times

[icholy]

Description

I started getting the following error when running :PackerCompile

[NvimTree] nvim-tree.lua setup called multiple times

Neovim version

NVIM v0.8.0-dev
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/cc -g -O2 -fdebug-prefix-map=/build/neovim-Ed2VZg/neovim-0.7.0~ubuntu1+git202206012118-57a296d89-dd05b3569=. -fstack-protector-strong -Wformat -Werror=format-security -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_TS_HAS_SET_MATCH_LIMIT -DNVIM_TS_HAS_SET_ALLOCATOR -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wdouble-promotion -Wmissing-noreturn -Wmissing-format-attribute -Wmissing-prototypes -Wimplicit-fallthrough -Wsuggest-attribute=pure -Wsuggest-attribute=const -Wsuggest-attribute=malloc -Wsuggest-attribute=cold -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/build/neovim-Ed2VZg/neovim-0.7.0~ubuntu1+git202206012118-57a296d89-dd05b3569/build/config -I/build/neovim-Ed2VZg/neovim-0.7.0~ubuntu1+git202206012118-57a296d89-dd05b3569/src -I/build/neovim-Ed2VZg/neovim-0.7.0~ubuntu1+git202206012118-57a296d89-dd05b3569/.deps/usr/include -I/usr/include -I/build/neovim-Ed2VZg/neovim-0.7.0~ubuntu1+git202206012118-57a296d89-dd05b3569/build/src/nvim/auto -I/build/neovim-Ed2VZg/neovim-0.7.0~ubuntu1+git202206012118-57a296d89-dd05b3569/build/include
Compiled by buildd@lcy02-amd64-014

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/share/nvim"

Run :checkhealth for more info

Operating system and version

5.13.0-44-generic #49~20.04.1-Ubuntu SMP Wed May 18 18:44:28 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

nvim-tree version

a0f7059

Minimal config

vim.cmd("packadd packer.nvim")

require("packer").startup(function(use)
  use({
      "kyazdani42/nvim-tree.lua",
      config = function()
        require("nvim-tree").setup()
      end
  })
end)

Steps to reproduce

:PackerCompile

Expected behavior

No output

Actual behavior

[gegoune]

As is says on the tin: you have more than one call to .setup() function for nvim-tree in your configuration. Only single setup is allowed. Find and remove extraneousness ones.

[icholy]

@gegoune do you mind helping me find it in the minimal config I provided?

[gegoune]

It might have something to do with packer and its config key. You could try to move setup call to init.lua to rule out packer.

[alex-courtis]

Doc updated to explicitly state "one call" and not use a config callback in the plugin manager.

[icholy]

Wait, so I have to restart the editor every time I want to tweak a config option?

[alex-courtis]

Wait, so I have to restart the editor every time I want to tweak a config option?

That is correct.

A PR to add such functionality would be gratefully accepted. Please note that the task is not small.

[kyazdani42]

Indeed, i'm not sure how most plugins do that, we should explore solutions first.

[maxdiebold]

My workaround was to still use Packer to manage it, but moved the setup call outside of the Packer startup function.

[dominicpalmer]

In the absence of a full setup guard implementation whereby the setup function isn't able to be called multiple times, sending a warning through to the user is probably going to be more unhelpful and annoying than anything else. It certainly has been for me, because I'm recalling setup at times with full knowledge I shouldn't, as it's within a module that gets rerun when other parts of my config changes dynamically (e.g. when switching themes without restarting Vim).

Sending a warning message everytime the function is recalled doesn't really add anything that the user wouldn't otherwise be able to read in the doc now that 3aeb59b has been merged too. If a user is actively trying to run setup multiple times and they find it doesn't work, they should read the docs. I'd like to make the case for reverting b1ecb75 and altering the new docs wording to no longer state that a warning is produced.

[icholy]

What about adding an option to suppress that warning message?

[dominicpalmer]

@alex-courtis Please see above. I've raised a PR to wrap the warnings in an option, as suggested by @icholy.