I have next oil.nvim setup (in lazy.nvim of course):

return {

        cmd = { "Oil" },
        event = { "FileExplorer" },

        opts = {
            -- Oil will take over directory buffers (e.g. `vim .` or `:e src/`)
            -- Set to false if you still want to use netrw.
            default_file_explorer = true,
         --   ...

Also, I have keyibnd for oil.nvim set:

vim.keymap.set("n", "-", "<CMD>Oil<CR>", { desc = "Open parent directory" })

The FileExplorer event is described in :h autocmd as:

There is one group that is recognized by Vim: FileExplorer.  If this group
exists Vim assumes that editing a directory is possible and will trigger a
plugin that lists the files in that directory.  This is used by the |netrw|
plugin.  This allows you to do:  
    browse edit

So, it should meet my requirements, the oil.nvim should be loaded when the :Oil is triggered, or, when I open nvim as $ nvim ., and the oil.nivm gets loaded and replaces the netrw.

If I try to run this config, I get next errors:

enter image description here

This is the output from $ nivm. When I run $ nvim . I get the same errors and the netrw file manager open, instead of oil.nvim. If I remove the event, then $ nvim . opens netrw because no :Oil command has ben triggered. Of course, if I remove the cmd and event everything works as intended, but I get no lazy loading for oil.nvim.

The question is: Why the event FileExplorer is invalid? How to lazy load oil.nvim so it will work with $ nvim .?

  • 1
    FileExplorer is a group, not event. Directory is just a special file, so there is no event for a directory to open. Only a generic one for a file.
    – Matt
    Commented Jan 10 at 21:14
  • @Matt Dang. Thank you for explanation. It seems like there is no way to properly lazy-load oil.nvim... Commented Jan 11 at 13:04
  • Lazy loading is to be implemented by plugin's author, not by user.
    – Matt
    Commented Jan 11 at 14:03
  • @Matt Really? Like if I pass lazy = true pluginspec, the plugin will know that he is being lazy-loaded and do something about it? Am I getting it right? Commented Jan 11 at 18:47
  • 1
    No, a well-designed plugin should keep events/commands/mapping registration separate from the core functionality code base being loaded on demand. Then users will never had any reason to re-implement such stuff themselves.
    – Matt
    Commented Jan 11 at 20:22


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.