Race Condition With open_on_setup

[alex-courtis]

Description

Inconsistent behaviour is occurring with the following options:

open_on_setup
open_on_setup_file
ignore_buffer_on_setup
disable_netrw
hijack_netrw

Neovim version

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

Operating system and version

Linux 5.17.5-arch1-1

nvim-tree version

7293f8d

Minimal config

vim.cmd [[set runtimepath=$VIMRUNTIME]]
vim.cmd [[set packpath=/tmp/nvt-min/site]]
local package_root = "/tmp/nvt-min/site/pack"
local install_path = package_root .. "/packer/start/packer.nvim"
local function load_plugins()
  require("packer").startup {
    {
      "wbthomason/packer.nvim",
      "kyazdani42/nvim-tree.lua",
      "kyazdani42/nvim-web-devicons",
      -- ADD PLUGINS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
    },
    config = {
      package_root = package_root,
      compile_path = install_path .. "/plugin/packer_compiled.lua",
      display = { non_interactive = true },
    },
  }
end
if vim.fn.isdirectory(install_path) == 0 then
  print "Installing nvim-tree and dependencies."
  vim.fn.system { "git", "clone", "--depth=1", "https://github.com/wbthomason/packer.nvim", install_path }
end
load_plugins()
require("packer").sync()
vim.cmd [[autocmd User PackerComplete ++once echo "Ready!" | lua setup()]]
vim.opt.termguicolors = true
vim.opt.cursorline = true

-- MODIFY NVIM-TREE SETTINGS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
_G.setup = function()
  require("nvim-tree").setup {
	  open_on_setup = true,
	  open_on_setup_file = false,
	  ignore_buffer_on_setup = true,
	  disable_netrw = false,
	  hijack_netrw = true,
  }
end

Steps to reproduce

vim -nu /tmp/nvt-min.lua <file> sometimes opens the tree
nvim -nu /tmp/nvt-min.lua sometimes opens the tree
nvim -nu /tmp/nvt-min.lua . sometimes opens netrw

Expected behavior

No response

Actual behavior

No response

[alex-courtis]

Alternatives like:

    open_on_setup = false,
    open_on_setup_file = true,
    ignore_buffer_on_setup = true,

Show similarly inconsistent behaviour.

[alex-courtis]

See #1262

[kyazdani42]

Some things we have to note with opening on setup:

• users with lazy-loading
• users using a rooter plugin (which might itself be lazy loaded somehow)
• users with open on setup enabled
• users with open on setup enabled, opening nvim to commit, or read a manpage export MANPAGER="nvim +Man!"
• users without open on setup enabled, with hijack directories enabled, opening a directory nvim $HOME
• users without open on setup enabled, with open file enabled, opening a file nvim file.lua

There might be other cases too, that's why it's quite complicated to handle this altogether.

• hijack directories will hijack netrw windows because these are directories (it's stated in the docs i believe).
• when a user is opening nvim tree when nvim starts up, nvim tree will run before nvim is loaded (filename, current cwd and such will be wrong), that's why we have to schedule the call.
• running nvim tree without hijacking netrw can cause very strange behaviors, because you will actually have 2 file explorers running, and thus user config options for nvim tree can very much make nvim unstable.

I'm pretty sure there are many other edge cases during nvim startup that i cannot remember right now, but that's why managing this feature is quite a challenge.

[alex-courtis]

I'm pretty sure there are many other edge cases during nvim startup that i cannot remember right now, but that's why managing this feature is quite a challenge.

Yes. This is not something we can fix quickly or easily. I opened this mainly to track the behaviour I have noticed.

There are no outstanding issues besides perhaps #1262. Let's wait until we have an urgent issue or more reports of such behaviour.

[alex-courtis]

#286 (comment) showed good results setting g:loaded_netrw before anything else.

Documentation to do the above on problems may be enough. Removing them from setup is also an option; it is just not reliable.

[alex-courtis]

Added doc to eagerly disable netrw: fb8735e

[alex-courtis]

Setup is now more stable via a variety of bugfixes.

Eager disable of netrw appears successful.