FEATURE: Better netrw hijacking about neo-tree.nvim HOT 4 OPEN

Thanks for sharing, but there are two problems with this setup:

1. It requires that netrw be enabled, while the current setup does not. I know that I disable unused plugins like that.
2. Since you have to wait for the netrw window to load first, that adds a delay every time it is used and likely a visual flash that some people will notice.

Given the above, it really doesn't seem to be an improvement at all.

If your goal is a faster startup time, does netrw actually initialize faster than neo-tree? If so, I would rather optimize neo-tree's internally lazy loading so that it does need to be lazy loaded by the plugin manager. Then again, if your goal is to be able to netrw hijack at startup, then neo-tree shouldn't be lazy loaded at all, should it?

I don't think the use case of still using netrw and neo-tree at the same time is a reasonable default. If I wanted to access remote files, I would much rather use netman.nvim than netrw.

from neo-tree.nvim.

it adds a delay the first time you use neo-tree (when the plugin is initially lazy-loaded) and the delay in question is just loading neo-tree instead of everything at once, which took 100ms on a raspberry pi, you also don't wait for netrw to load before loading neo-tree, you only wait on the replacing part (the filetype is set quite early)
also the non-lazy implementation also adds a delay, both on opening a file buffer and on initial load, both of which can be seen as a flash

folder current: total 155ms/287ms, neotree 65ms
file current: total 184ms/367ms, neotree 66ms
folder lazy: total 93ms/286ms, neotree+netrw 87ms
file lazy: total 88ms/280ms, (later than start ->) neotree+netrw 50ms

the total times don't change much for folders, but they're distributed across different moments for files, which makes them feel faster

also i only want to hijack netrw at startup when i'm opening a folder, if i'm opening a file i don't want either to load - which the lazy solution accomplishes

netrw only loads when opening a folder, so it takes 0ms when editing files, while neo-tree hijacking still has to load the plugin even if it's not immediately used

edit: also, netman.nvim crashes for me, i don't know why

from neo-tree.nvim.

version 2:
the following results in no netrw overhead and full lazy-loading:

{
  'nvim-neo-tree/neo-tree.nvim',
  cmd = 'Neotree',
  init = function()
    vim.api.nvim_create_autocmd('BufEnter', {
      -- make a group to be able to delete it later
      group = vim.api.nvim_create_autogroup('NeoTreeInit', {clear = true}),
      callback = function()
        local f = vim.fn.expand('%:p')
        if vim.fn.isdirectory(f) ~= 0 then
          vim.cmd('Neotree current dir=' .. f)
          -- neo-tree is loaded now, delete the init autocmd
          vim.api.nvim_clear_autocmds{group = 'NeoTreeInit'}
        end
      end
    })
    -- keymaps
  end,
  opts = {
    filesystem = {
      hijack_netrw_behavior = 'open_current'
    }
  }
}

folder lazy: total 123ms/194ms, neotree 64ms
file lazy: total 94ms/245ms, (later ->) neotree 90ms

this version loads neo-tree before netrw, and so does not load netrw for local files due to hijacking, by adding:

vim.g.loaded_netrwPlugin = 1
vim.g.loaded_netrw = 1

you can also disable netrw for remote file viewing and the above still works

from neo-tree.nvim.

For what it's worth, when using the suggested netrw hijacking behavior, I already see the visual flash you describe @cseickel, which is what led me to this issue.

@Aonodensetsu Thanks a bunch for your latest suggestion, as I'm finally getting smooth hijacking behavior (AND it's lazily loaded so my startup time has sped up by 25%... i.e. 10ms... every bit counts lol)

from neo-tree.nvim.