Can't be lazy loaded by plugin managers

[amerlyq]

Actually, when using with dein.vim inside neovim, lazy loading don't work.
Even when using 'hook_post_source': 'sil! exe "do FileType" &ft' to enforce re-applying of ftplugin files.
What exactly I must do to correctly initialize plugin, if current buffer was loaded before plugin itself ?

[AndrewRadev]

The plugin has per-filetype configuration. This is kind of necessary, since different filetypes have different methods of splitting and joining. As an example, the ruby filetype configuration is in ftplugin/ruby/splitjoin.vim: https://github.com/AndrewRadev/splitjoin.vim/blob/10e93ae9b25cf4d56ab452633bb782f55098ae16/ftplugin/ruby/splitjoin.vim

Normally, the plugin's directory needs to be in the runtimepath. When a filetype is detected, all appropriately-named files in the runtimepath that are connected to it get evaluated (ftplugin/ruby.vim, ftplugin/foo/ruby.vim).

I'm not familiar with how dein does its lazy loading, but I assume it doesn't add the plugin's directory to the runtimepath directly. The re-application of ftplugin files should work, theoretically... Though it might be that dein doesn't add ftplugin dirs to the runtime path? I'll try to look into dein's source code, see what I can find.

My general advice, however, is to not bother. The bulk of splitjoin code is already autoloaded, and the ftplugin files are loaded only when you open a particular filetype. And even then, their content is literally setting a single variable. I really don't think you'll save any significant startup time by lazy-loading it. Try measuring it with the "startuptime" feature (:help --startuptime)

[amerlyq]

The plugin has per-filetype configuration.

I have nothing to retort. Moreover, I strongly encourage your way of using separate ftplugin instead of autocmd.

About dein.vim's lazy loading -- it creates proxies for user-registered mappings, commands and functions.
Therefore any of plugin's files won't be loaded until user hit some proxy -- which adds plugin to &rtp, loads it and replaces mappings with actual ones.

I bother because of many reasons:

• I have >100 plugins and almost all of them are lazy-loaded, therefore any non-lazy is exception.
• In most of my wm+ranger workflow each vim instance live ~10-40 seconds -- so any delay severely impacts me, and fatigue accumulates throughout the day.
• Most of opened instances are used for view only or for some small fix, which means I don't need this plugin most of the time -- and therefore don't want it to affect anything in any way, even by minuscule amount.
• Using autoload/ isn't panacea. Vim always loads plugin/, which often calls to some autoload/ functionality. Even if it's scope restricted, you have chain effect of file dependencies. And even if you exceptionally clean in coding style -- loading even single file from autoload/ results in kernel trying to resolve/access dnode of directory, containing that file. Which can sustain much time on highly loaded system, until scheduller allocate some time quants for vim.
• When using vim on system with HDD -- all those fractions of millisecond (on SSD) becomes fractions of seconds -- even more so, if some firmware is being built in the background resulting in huge load.
• Cold start of vim is long and even for those several files the disk access matters.
• Experience of adapting aforementioned exceptions amongs plugins to lazy loading ways often points me to the fact of abusing some of vim functionality and possibly somewhat unrefined architecture. Therefore anything which was fixed for lazy loading has much more robust architecture.

[AndrewRadev]

I also have a lot of plugins. I have zero lazy-loading and my Vim starts in 211ms. That's faster than I can register. From that time, a very, very, very small amount comes from splitjoin:

times in msec
 clock   self+sourced   self:  sourced script
 clock   elapsed:              other lines

166.890  000.029  000.029: sourcing /home/andrew/.vim/bundle/splitjoin/autoload/sj/settings.vim
167.047  000.505  000.476: sourcing /home/andrew/.vim/bundle/splitjoin/plugin/splitjoin.vim

That's fractions of a millisecond. The settings autoload file is the only one that is loaded eagerly, and it's 43 lines that define two functions and a variable.

And yes, I use an SSD, a pretty modern computer, and I'm not compiling firmware in the background :). So maybe in your case you need it, but I would recommend making some experiments and measuring the results anyway. Remember that dein also does some work which has some overhead. Even the documentation says that using laziness when you don't need it just increases the overhead: https://github.com/Shougo/dein.vim/blob/68ceee0342260fb843457e2f09ff5cb653c59121/doc/dein.txt#L665-L668

Either way, this doesn't actually matter to me. It's your choice whether you want to use lazy-loading or not. The issue here is: why does the plugin not work with this particular plugin framework.

---

I tried the following:

• I moved the splitjoin plugin where it would not be added to the runtimepath.
• I opened a ruby file and checked that splitjoin was not working
• I added splitjoin to the runtimepath with set rtp+=~/path/to/splitjoin
• I executed the plugin file with runtime plugin/splitjoin.vim
• I ran the command you pointed out you were also running: exe "do FileType" &ft

After this, splitjoin seemed to be working. To me, this indicates that it might be a problem with dein. Looking at the source code, I see this line here, which finds an ftplugin/ directory: https://github.com/Shougo/dein.vim/blob/68ceee0342260fb843457e2f09ff5cb653c59121/autoload/dein/autoload.vim#L337. And, afterwards, there's this line which globs for ftplugin/<filetype>_*.vim: https://github.com/Shougo/dein.vim/blob/68ceee0342260fb843457e2f09ff5cb653c59121/autoload/dein/autoload.vim#L344.

So, it might be that dein is looking for ftplugin/<filetype>_*.vim files, but not for ftplugin/*/<filetype>.vim files, like splitjoin uses.

I'm not 100% sure of this, because I'm not sure if this is the function I should be looking for, it's a reasonably complicated plugin, and I can't be sure I completely understand it. Could you open an issue to dein.vim and ask if the plugin supports ftplugin/<plugin-name>/<filetype>.vim filetypes? You could explain the situation with splitjoin as an example: https://github.com/AndrewRadev/splitjoin.vim/tree/10e93ae9b25cf4d56ab452633bb782f55098ae16/ftplugin

[amerlyq]

Actually, dein.vim only checks if there is any &ft file to make decision on loading.
And actually it checks isdirectory(ftplugin) -- therefore aforementioned assumption isn't relevant.
I checked my plugins list, and there are multiple ones, which work fine.

davidhalter/jedi-vim/after/ftplugin/{python}
davidhalter/jedi-vim/ftplugin/{python}
eagletmt/ghcmod-vim/after/ftplugin/{haskell,lhaskell}
kana/vim-textobj-function/after/ftplugin/{c,java,vim}
klen/python-mode/ftplugin/{pyrex.vim,python}
wmvanvliet/vim-ipython/ftplugin/{python}

By the way, using with trigger 'on_ft': ['perl', ...] lazy loading works just fine.
Can't derive the reason from dein.vim sources, though.
Anyway, most probably its not the problem of your's plugin.
But I will investigate slightly more deeper before submitting issue.
Maybe some configuration trick on my side could become the deal.

[rafi]

This works for me:

call dein#add('AndrewRadev/splitjoin.vim', { 'on_map': { 'n': '<Plug>Splitjoin' }})
call dein#add('AndrewRadev/sideways.vim', { 'on_map': { 'ox': '<Plug>Sideways' }})
call dein#add('AndrewRadev/dsf.vim', { 'on_map': { 'n': '<Plug>Dsf' }})
call dein#add('AndrewRadev/linediff.vim', { 'on_cmd': 'Linediff' })

[AndrewRadev]

At this time, I don't know if there's anything actionable for me to do on this ticket, so I'll go ahead and close it. If more people run into lazy-loading issues and have some advice on what might fix them, please reopen or open a new issue.