incompatible with nvim-tree if one option is activated

[emmanueltouzery]

i now upgraded my nvim-tree and realized it's broken with stickybuf if one nvim-tree option is active.

I'm guessing it's unfixable from stickybuf, but I guess at least we should add a message in the readme to warn users about that.

The nvim-tree feature in question is highlight_opened_files. When that option is activated, nvim-tree will highlight in the treeview files for which there is an open buffer in neovim.
Unfortunately, so that it removes the highlighting when you close such a file, it registers an autocmd tied to BufUnload against any buffer in neovim (not only buffers it owns):

https://github.com/nvim-tree/nvim-tree.lua/blob/c763861afb32f839555f9e797f4392f54ef4ad23/lua/nvim-tree.lua#L234

In the callback, it notes the buffer number that was closed and triggers a refresh of the treeview, removing the highlight for that buffer number. Unfortunately, when stickybuf is operating, it will get the buffer number wrong at the very least, but in my case it triggers some chain reaction that I don't fully understand and the outcome is that when I start neovim and open the first file, I'm in insert mode in that file instead of normal mode.

And if I disable the nvim-tree highlight_opened_files option, or uninstall stickybuf, the issue goes away. Note that disabling the nvim-tree support in stickybuf is not enough, because as I said it's not about the nvim-tree buffers, it's about any buffer being unloaded in the entire neovim app.

So yes.. Unless you can think of a trick to fix that, I guess we'd need to warn that running nvim-tree in that configuration is unsupported. It's a shame but...

[emmanueltouzery]

note that older versions of nvim-tree which already had the feature were not affected by this conflict with stickybuf. For instance, the basically one-year-old version of c446527056e92a57b51e2f79be47c28ba8ed43e4 was not affected. But I guess they changed the behavior of nvim-tree for a good reason...

In my case I think I'll stick with an older version of nvim-tree so I can keep using nvim-tree with that feature and also stickybuf.

[stevearc]

Yeah hard to tell what could be done to fix it when the root cause isn't known. There's got to be more going on because while stickybuf does delay when BufUnload is called, that should be more-or-less the only difference. If you can find the root cause, we might be able to fix it either in stickybuf or in nvim-tree

[emmanueltouzery]

isn't the problem that by the time nvim-tree is invoked, it's invoked on the wrong buffer?

[stevearc]

My current understanding of the bug is "nvim-tree with this option enabled causes my first file opened to be in insert mode". Given that, I have no idea what could actually be happening under the hood. From just the description of what could be happening (BufUnload autocmds), that doesn't sound like enough to cause problems by itself. BufUnload passes the unloaded buffer in the context of the autocmd, so I have no reason to assume that nvim-tree is operating on the wrong buffer.

[emmanueltouzery]

i tried to look into this some more, but it's not all that simple. Here is what I see:

1. stickybuf BufHidden handler is called. prev_bufhidden is wipe.
2. nvim-tree BufUnload is called. It seems the only thing that matters to trigger my issue is whether vim.bo[data.buf].buftype is invoked in that callback. If it's invoked, even if the only line in the handler is print its value, I'll have the issue. If it's not invoked, no problem. It doesn't seem to throw an exception though, if I put a print statement after it, it's printed. Also, replacing the call with pcall(vim.api.nvim_buf_get_var, data.buf, "buftype") fixes the issue
3. stickybuf defer_fn is invoked, and seems to execute normally

Note that I'm using neovim 0.9.1. My messages is clean and I have no idea what triggers the move to insert mode. I would have to disable all my plugins I guess, and try other neovim versions but...

For now I cannot understand the significance of that call to read the buffer type.

So, to be clear, that change in nvim-tree fixes the issue for me:

  create_nvim_tree_autocmd("BufUnload", {
    callback = function(data)
      -- update opened file buffers
+      local ok, buf_type = pcall(vim.api.nvim_buf_get_var, data.buf, "buftype")
+      if ok and (filters.config.filter_no_buffer or renderer.config.highlight_opened_files ~= "none") and buf_type == "" then
-      if (filters.config.filter_no_buffer or renderer.config.highlight_opened_files ~= "none") and vim.bo[data.buf].buftype == "" then
        utils.debounce("Buf:filter_buffer", opts.view.debounce_delay, function()
          reloaders.reload_explorer(nil, data.buf)
        end)
      end
    end,
  })

[emmanueltouzery]

my change should be calling nvim_buf_get_option, not nvim_buf_get_var.
and yes, calling it with get_option also fixes the issue.

[tan-wei]

Met the same issue. :-(

Seems hard to fix.

[emmanueltouzery]

@tan-wei presumably your symptoms aren't exactly the same as mine?

[tan-wei]

Hmm, I don't know. But I think I met a problem just like here. I don't know why.