On-demand loading plugins without 'plugin', 'ftdetect', 'after/ftdetect', and 'after/plugin' directories

[adammaleszka]

There are two plugins written in lua, let say completion-nvim and lsp-status.nvim.

Looking at their structure, they are almost the same. They both have lua directory and they are both loaded using require. The main --- in this case --- difference is that completion-nvim contains plugin folder, but lsp-status.nvim does not.

Both completion-nvim and lsp-status.nvim are set to be loaded lazily (on demand):

Plug 'nvim-lua/completion-nvim', {'on': 'Demand'}
Plug 'nvim-lua/lsp-status.nvim', {'on': 'Demand'}

So after opening Neovim none of them should be loaded. However, it is not clear why it is not the case. :PlugStatus reports that completion-nvim is not loaded, but lsp-status.nvim is. Requesting module completion-nvim with require populates error, but lsp-status.nvim loads well. completion-nvim cannot be found in the runtimepath, but lsp-status.nvim is listed and so on.

Adding plugin or after/plugin or ftdetect or after/ftdetect folder to lsp-status.nvim resolves problem, lsp-status.nvim becomes treated as not loaded. This fix applies to any other cases.

Summary

Current behavior

Plugins without any of the directories listed in the title cannot be loaded on-demand, it's they are added to runtimepath at startup. This behavior makes it impossible to load plugins (with lua directory only) on-demand what is essential to restrict
specific modules.

Expected behavior

Any plugin that is marked to be loaded lazily should not be loaded at startup, even if the plugin does not include folders listed in the title.

---

NVIM v0.5.0
Build type: MinSizeRel
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/cc -DNVIM_TS_HAS_SET_MATCH_LIMIT -Os -DNDEBUG -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/home/debianx64/Documents/oth/build/neovim/build/config -I/home/debianx64/Documents/oth/build/neovim/src -I/home/debianx64/Documents/oth/build/neovim/.deps/usr/include -I/usr/include -I/home/debianx64/Documents/oth/build/neovim/build/src/nvim/auto -I/home/debianx64/Documents/oth/build/neovim/build/include
Compiled by debianx64@debianx64

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/local/share/nvim"

Run :checkhealth for more info

• Type:
  • Bug
  • Enhancement
  • Feature Request
  • Question
• OS:
  • All/Other
  • Linux
  • OS X
  • Windows
• Vim:
  • Terminal Vim
  • GVim
  • Neovim

[janlazo]

function! s:lazy(plug, opt)
  return has_key(a:plug, a:opt) &&
        \ (empty(s:to_a(a:plug[a:opt]))         ||
        \  !isdirectory(a:plug.dir)             ||
        \  len(s:glob(s:rtp(a:plug), 'plugin')) ||
        \  len(s:glob(s:rtp(a:plug), 'after/plugin')))
endfunction

Expected behavior because on-demand loading is meant for plugin/ directory. #786

[junegunn]

I have to add that I strongly advise against using on/for hack.

https://github.com/junegunn/vim-plug/wiki/faq#when-should-i-use-on-or-for-option

If a plugin has a startup-time problem, you should report that to the author of the plugin, so that they fix properly address the issue.

[adammaleszka]

@janlazo On-demand loading does not affect only plugin directory --- that is what I wanted to say in the first message.

This, whether the plugin is loaded or not, affects runtimepath. However, on runtimepath depends loading of plugin but also of autoload and --- in the case of Neovim --- of lua also.

Why would loading the lua folder depend on whether the plugin folder exists?

I understand what on-demand loading is for. It speeds up startup-time of Neovim by keeping the plugin folder unloaded during startup. However, the situation is a bit different, because on-demand loading affects other directories also (e.g. lua).

[adammaleszka]

@junegunn Yes, I agree with you that on-demand loading is used rarely these days. But…

My configuration of Neovim consists of about 40 plugins. None of them has a lot in plugin folder. However, my Neovim instance loads for about 0.7 seconds. It is really a lot.

Struggling with performance issue I writed a new configuration. All plugins are loaded lazily and they are loaded automatically (by a module-based solution) when they are needed. In this case it is important to have possibility to "disable" a specific plugin, it is --- have it unloaded. Can't I really disable a plugin that is written in lua, just because there is no plugin folder?

[adammaleszka]

In my opinion, behavior introduced as an "expected" one is more intuitive: if the user wants to have a module unloaded, let it be unloaded. However, if you don't agree with me, no problem. Thank you (@janlazo) for pointing me the relevant commit.

Thank you @junegunn for maintaining the best plugin manager I have ever seen.

[junegunn]

Should be fixed by #1157