FEATURE: Better netrw hijacking

[Aonodensetsu]

Did you check the docs?

• I have read all the docs.

Is your feature request related to a problem? Please describe.

When lazy-loading plugins, neo-tree cannot be lazy-loaded if you want it to hijack netrw properly (upon opening neovim with a folder argument). I made a fix that I want to share.

Describe the solution you'd like.

My fix allows full lazy-loading, keeps netrw for remote files (since I don't think neo-tree supports those). I would like for it to be integrated into neo-tree, as I feel it aligns with the goal of 'UX good'.

-- vim.bo.filetype is `:set filetype`, which netrw is nice enough to use
-- vim.b.netrw_method is `let b:netrw_method` - nil when editing local files (`:h netrw-fixup` for others)
if vim.bo.filetype == 'netrw' and vim.b.netrw_method == nil then
  -- wait until netrw loads fully, trying to close before will not work
  vim.defer_fn(function()
    -- the enew is required, if netrw is replaced directly it can leave some text below the tree if the tree is short
    -- (at least on my raspberry pi, may only be a problem on slow systems?)
    -- vim.b.netrw_curdir (`let b:netrw_curdir`) is the currently open folder
    -- which is what the user wants, since we replace netrw before any interaction
    vim.cmd('enew | Neotree current dir=' .. vim.b.netrw_curdir)
  end, 0)
end

Additional Context

Example configuration in lazy:

{
  'nvim-neo-tree/neo-tree.nvim',
  ft = 'netrw', -- load when netrw opens to replace it
  cmd = 'Neotree', -- load when calling keymaps
  init = function()
    -- make keymaps here to load them before the plugin itself
    -- they need to be in VimScript to not load the plugin prematurely
    -- they also need to begin with something specified in `cmd`
    -- (for this plugin, :Neotree has all of them i think?)
  end,
  config = function()
    require'neo-tree'.setup{
      filesystem = {
        hijack_netrw_behavior = 'open_current'
      }
    }
    if vim.bo.filetype == 'netrw' and vim.b.netrw_method == nil then
      vim.defer_fn(function()
        vim.cmd('enew | Neotree current dir=' .. vim.b.netrw_curdir)
      end, 0)
    end
  end
}

[cseickel]

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.

[Aonodensetsu]

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

[Aonodensetsu]

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_augroup('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

[j4ns8i]

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)

[gerazov]

Thanks for this 🙏 - it was hard to find!
Small typo nvim_create_autogroup -> nvim_create_augroup

[pysan3]

Nice. Maybe it's worth adding this to the wiki https://github.com/nvim-neo-tree/neo-tree.nvim/wiki/Tips @Aonodensetsu .

[Aonodensetsu]

@pysan3 I expanded the solution for remote files as well, but due to a bug in netman can't integrate that so far, I've opened an issue and will update tips after that gets closed.

This assumes loaded_netrw, works in either case

{
  'nvim-neo-tree/neo-tree.nvim',
  cmd = 'Neotree',
  init = function()
    -- the remote file handling part
    vim.api.nvim_create_autocmd('BufEnter', {
      group    = vim.api.nvim_create_augroup('RemoteFileInit', {clear = true}),
      callback = function()
        local f = vim.fn.expand('%:p')
        for _, v in ipairs{'dav', 'fetch', 'ftp', 'http', 'rcp', 'rsync', 'scp', 'sftp'} do
          local p = v .. '://'
          if f:sub(1, #p) == p then
            vim.cmd[[
              unlet g:loaded_netrw
              unlet g:loaded_netrwPlugin
              runtime! plugin/netrwPlugin.vim
              silent Explore %
            ]]
            break
          end
        end
        vim.api.nvim_clear_autocmds{group = 'RemoteFileInit'}
      end
    })
    vim.api.nvim_create_autocmd('BufEnter', {
      group = vim.api.nvim_create_augroup('NeoTreeInit', {clear = true}),
      callback = function()
        local f = vim.fn.expand('%:p')
        if vim.fn.isdirectory(f) ~= 0 then
          vim.cmd('Neotree current dir=' .. f)
          vim.api.nvim_clear_autocmds{group = 'NeoTreeInit'}
        end
      end
    })
    -- keymaps
  end,
  opts = {
    filesystem = {
      hijack_netrw_behavior = 'open_current'
    }
  }
}

[Aonodensetsu]

added the Tip finally

[miversen33]

Not sure why I never responded before but did whatever bug you mention get resolved in netman? If not, you should probably poke me with a stick to see if I am still alive ;)