`:Neotree current` creates "ghost" file tree after opening a file

[doongjohn]

:Neotree current creates "ghost" file tree after opening a file.
But it disappears after you press q to exit and reopen with :Neotree current.

[jonathonadams]

Same behaviour here, it started happening about 2 weeks ago for me, and I update my packages daily

[miversen33]

Please provide a minimal configuration so we can recreate your issue. As it stands right now, Neo-tree "works on my machine". Without additional context, it is going to be very difficult to provide any kind of assistance.

[doongjohn]

my config (using lazy.nvim):

return {
  -- file tree
  'nvim-neo-tree/neo-tree.nvim',
  dependencies = {
    'nvim-lua/plenary.nvim',
    'muniftanjim/nui.nvim',
    'kyazdani42/nvim-web-devicons',
  },
  keys = {
    { '<leader>e', '<cmd>Neotree show current<cr>' },
    { '<leader>E', '<cmd>Neotree show current reveal=true<cr>' },
  },
  config = function()
    require 'neo-tree'.setup {
      close_if_last_window = true,
      popup_border_style = 'solid',
      enable_git_status = true,
      enable_diagnostics = true,
      default_component_configs = {
        indent = {
          indent_size = 2,
          padding = 1, -- extra padding on left hand side
          with_markers = true,
          indent_marker = '│',
          last_indent_marker = '└',
          highlight = 'NeoTreeIndentMarker',
        },
        icon = {
          folder_closed = '',
          folder_open = '',
          folder_empty = "",
          default = '',
        },
        name = {
          trailing_slash = false,
          use_git_status_colors = true,
        },
      },
      filesystem = {
        filtered_items = {
          hide_dotfiles = false,
          hide_gitignored = false,
        }
      },
    }
  end
}

[jonathonadams]

I went back through the versions, and the last working version is 2.43, so it was introduced in 2.44.

This baffles me because I only moved to vim in Jan, and I swear it was working fine a couple of weeks ago.

@doongjohn can you confirm for me that the below fixes it?

{
  branch = "v2.x",
  tag = "2.43",
}

Edit: Apologies @miversen33, but minimal config

require("neo-tree").setup({
  window = {
    position = "current",
  }
})

[pysan3]

They should have put much much more consideration when merging #590 since it will break the assumption of there is no neo-tree instance that have the same tabid and source-name.

When close_all is NOT called before opening a neo-tree instance, it might end up using a corrupted cache of state that was stored in neo-tree.source.manager.source_data returned by neo-tree.source.manager.get_state().

The cleanest and easiest workaround is to add this line so that the content of old buffer is deleted but the state can be reused.

The old code should have had the pointer to Nuitree (reference to Nuitree object (table) stored in state.tree) attached to the old buffer, so focusing that buffer was the only thing we had to do.
This fix however requires to first clear the content of the old buffer rendered by the old corrupted Nuitree, and rerender the whole tree again from the groundup.

This process does not require a whole disk scan so it is done relatively quickly (mostly unnoticeable by human) but is indeed a limitation.

The in-depth explanation of what is going on is too complicated to explain but I'll probably try to investigate further for a better solution this weekend.

I'd love to hear any feedbacks from @miversen33 @cseickel and @Gelio as well.

[cseickel]

I don't get it, I'm not experiencing this issue and I use Neotree current almost exclusively to open files. I tried @doongjohn's config and I didn't have any issues.

[Gelio]

All I can say is I started experiencing this issue lately, but I haven't done any debugging to find the root cause. It was not #590 that unveiled it, since it was merged a long time ago. I am not knowledgeable enough on this codebase to have any opinion whether #1007 is right or not. I'll leave it up to more savvy engineers to decide. Thanks for working on it, @pysan3

[jonathonadams]

Likewise @Gelio, my experience has been that this is a much more recent thing.

However when I go back through the versions, 2.43 is the last version that doesn't present the issue.

I'm not familiar with the codebase at all, is there any chance another plugin could be causing it?