nvim-tree does not BufWinEnter when opening on VimEnter

[Iron-E]

Description

I am a maintainer for barbar.nvim, and we have a feature that allows users to adjust the offset of the tabline when a sidebar (such as nvim-tree) is open.

This works well most of the time, however, recently a user reported that this does not work when using the Open At Startup snippets from the wiki. Upon investigation, it appears that this is because nvim-tree does not emit a BufWinEnter event in this case. It is worth noting that when doing :NvimTreeToggle afterward, it does.

Neovim version

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

Operating system and version

6.2.10-arch1-1

nvim-tree version

48d53a5

Minimal config

vim.api.nvim_create_autocmd(
  {'BufWinEnter', 'FileType', 'WinNew', 'WinResized', 'WinScrolled'},
  {callback = function(event) vim.print(event) end}
)

vim.opt.rtp:append(vim.fn.stdpath('data') .. '/lazy/nvim-tree.lua')
require'nvim-tree'.setup {}

-- auto open nvim-tree when open neovim
local function open_nvim_tree(data)
  -- buffer is a real file on the disk
  local real_file = vim.fn.filereadable(data.file) == 1

  -- buffer is a [No Name]
  local no_name = data.file == '' and vim.bo[data.buf].buftype == ''

  -- only files please
  if not real_file and not no_name then
    return
  end

  -- open the tree but dont focus it
  require('nvim-tree.api').tree.toggle({ focus = false })
end

vim.api.nvim_create_autocmd({'VimEnter'}, { callback = open_nvim_tree })

It also happens with tree.open

Steps to reproduce

1. nvim --clean -u minimal.lua
2. Observe that a BufWinEnter event is not printed on startup for the NvimTree buffer.

Expected behavior

It follows the event sequence that happens when executing :NvimTreeToggle after startup concludes:

{
  buf = 2,
  event = "FileType",
  file = "NvimTree_1",
  id = 14,
  match = "NvimTree"
}
{
  buf = 1,
  event = "WinNew",
  file = "",
  id = 14,
  match = ""
}
{
  buf = 2,
  event = "BufWinEnter",
  file = "/home/iron-e/NvimTree_1",
  id = 14,
  match = "/home/iron-e/NvimTree_1"
}

You can verify the above by using this snippet:

vim.opt.rtp:append(vim.fn.stdpath('data') .. '/lazy/nvim-tree.lua')
require'nvim-tree'.setup {}

-- start listening to autocmds AFTER vim enter; reduces noise
vim.api.nvim_create_autocmd('VimEnter', {callback = function()
  vim.api.nvim_create_autocmd(
    {'BufWinEnter', 'FileType', 'WinNew', 'WinResized', 'WinScrolled'},
    {callback = function(event) vim.print(event) end}
  )
end})

Then manually typing :NvimTreeToggle.

Actual behavior

{
  buf = 1,
  event = "BufWinEnter",
  file = "",
  id = 3,
  match = ""
}

{
  buf = 2,
  event = "FileType",
  file = "NvimTree_1",
  id = 3,
  match = "NvimTree"
}
-- no ButWinEnter for `buf = 2`

[alex-courtis]

Vim events will be the death of me. They are undpredictably deterministic, especially around startup.

This behavour doesn't appear to be nvim-tree specific. BufWinEnter, WinNew etc. are not fired during VimEnter.

Experimented with vim.schedule with good results:

vim.api.nvim_create_autocmd({ "VimEnter" }, {
  callback = function()
    local log = require("nvim-tree.log")
	log.line("dev", "VimEnter START %s", vim.inspect(vim.opt.eventignore:get()))
	vim.schedule(function()
		require('nvim-tree.api').tree.toggle({ focus = false })
	end)
	log.line("dev", "VimEnter END   %s", vim.inspect(vim.opt.eventignore:get()))
  end,
})

[alex-courtis]

Reproduce without nvim-tree

vim.api.nvim_create_autocmd({ "BufWinEnter", "FileType", "WinNew", "WinResized", "WinScrolled" }, {
  callback = function(event)
    local log = require("nvim-tree.log")
    log.line("dev", "%d %-15s %s", event.buf, event.event, event.file)
  end,
})

vim.api.nvim_create_autocmd({ "VimEnter" }, {
  callback = function()
    local log = require("nvim-tree.log")
	log.line("dev", "VimEnter START %s", vim.inspect(vim.opt.eventignore:get()))
	vim.api.nvim_command "vsp"
	vim.api.nvim_command "e bar"
	log.line("dev", "VimEnter END   %s", vim.inspect(vim.opt.eventignore:get()))
  end,
})

[2023-04-15 14:07:25] [dev] 1 BufWinEnter
[2023-04-15 14:07:25] [dev] VimEnter START {}
[2023-04-15 14:07:25] [dev] VimEnter END   {}

[alex-courtis]

Comment out VimEnter and see the missing events:

echo foo > bar
vi
:vsp
:e bar

[2023-04-15 14:08:46] [dev] 1 BufWinEnter
[2023-04-15 14:08:50] [dev] 1 WinNew
[2023-04-15 14:08:50] [dev] 1 WinResized      1001
[2023-04-15 14:08:50] [dev] 1 WinScrolled     1001
[2023-04-15 14:08:52] [dev] 2 BufWinEnter     /home/alex/src/river-xmonadwm/bar

[Iron-E]

I see, so this isn't nvim-tree specific. Is there an upstream issue for this? For now I can just add this to the "Limitations" section of our repo, since I can see that this could affect any sidebar_filetype users might want to open on startup.

[alex-courtis]

I see, so this isn't nvim-tree specific. Is there an upstream issue for this? For now I can just add this to the "Limitations" section of our repo, since I can see that this could affect any sidebar_filetype users might want to open on startup.

Many thanks. I'm not aware of an upstream issue.

I don't think it would be possible for neovim to fix this without breaking a lot. It seems that vim legacy is holding neovim back when it comes to events. You might raise an issue / PR to update the neovim event documentation to indicate this behaviour.

[alex-courtis]

P.S. you might try a nested autocommand.

My experience has been poor and I avoid them. There is the risk of infinite loops.