Vundle.vim: Need to run PluginInstall or :BundleInstall each time.

[raghur]

hi,
lately, there seems to be a problem with Vundle. Basically, some plugins aren't loaded unless I issue :PluginInstall or :BundleInstall each time after starting gvim. My vim config is at: https://github.com/raghur/vimfiles

Gvim 7.4 32bit on Windows7x64 with Huge features and patches 1-250

[Shougo]

I checked your .vimrc, but your .vimrc is too long.
You should upload .vimrc less than 50 lines.

[starcraftman]

Hi @raghur. To better solve this please:
1) Identify exactly what plugins don't load.
2) I'd suggest clearing your vimrc file and using the minimal example in quickstart. Then clean out all the example Plugin lines and just add back the commands you identified in 1 to see if it works.

If the plugins work after step 2 then it is probably the other lines in your vimrc.

[raghur]

Ok - I am able to repro this with a minimal vimrc file - here's a gist with the vimrc file, :scriptnames output after starting gvim with gvim -U $HOME/.vimrc2
Then I ran :PluginInstall and again ran :scriptnames - now the list has 160 odd entries.

https://gist.github.com/raghur/10157032

[starcraftman]

@raghur
There is some strange bug going on. For some reason, on GVim Windows the scripts on the rtp are not being sourced in properly. If you look at the rtp though they are properly there. For example, when I tested vim-airline consistently didn't source on startup. After PluginInstall vim-airline was sourced.

The rtp is so long that writing set rtp? doesn't list it all, use echo &rtp to see it. Not sure what's going on here.

[raghur]

@starcraftman - thanks for confirming that you can reproduce the issue.

[starcraftman]

@raghur I think this only happens on Windows, testing on my Linux PC with same config seems to read all the plugins/most correctly including airline (though I didn't test every one individually). Could there be some artefact about the way Windows vim works that it stops loading scripts after a certain number?

Any thoughts @jdevera?
Edit: Correction, to a lesser extend it may impact linux. I noticed a smaller delta between :scriptnames before and after PluginInstall. I'm not an expert on vim startup sequence so this may be a while investigating.

[starcraftman]

@raghur Do you mind trying something? Put the following line at the bottom of your vimrc. Tell me if all the plugins load.

call vundle#config#require(g:bundles)

It is a bit of a hack, shouldn't have to do that. I'm not sure why some of these aren't being sourced. This function appears to force sourcing of the vim scripts by some runtime! calls.

[raghur]

@starcraftman: Ok - I tried it out. I'm afraid it doesn't fix the issue. The behavior is weird though and maybe will help you spot a pattern:

vim-airline loads properly. I now get a count of 124 (vs the 107 without this line). However, some plugins _never_ load. for ex: vim-sparkup no longer loads. Even running a :PluginInstall does not help (:scriptnames remains fixed at 126)

UPDATE Correction: This does seem to load all the scripts.However, vim-sparkup no longer works (no mapping defined for <c-e> anymore - even if I close and open the HTML file

To summarize: Yes - adding this line seems to force load all scripts (based on scriptnames count). However, vim-sparkup specifically does not work anymore. vim-airline does work. But I have no idea if any other plugin is broken. One point to keep in mind is that vim-sparkup requires a rtp parameter - will that have any bearing?

[starcraftman]

@raghur You left the trailing / on the rtp parameter. Did you have that before? Can you try removing it. I believe that is mentioned in the windows wiki.

Back to the actual issue. The function is printed below, I'm not an expert but main difference seems to be the manual runtime function calls on line 30-31. It is a strange behaviour thing. Based on vimdocs, the plugins get read after the vimrc has finished. By that time the rtp is correct and all scripts in path/plugin/*.vim are read. Seems windows GVim doesn't honor this as strictly.

@gmarik @jdevera and @Shougo Do you guys have thoughts on this?

 25 func! vundle#config#require(bundles) abort
 26   for b in a:bundles
 27     call s:rtp_add(b.rtpath)
 28     call s:rtp_add(g:bundle_dir)
 29     " TODO: it has to be relative rtpath, not bundle.name
 30     exec 'runtime! '.b.name.'/plugin/*.vim'                                         
 31     exec 'runtime! '.b.name.'/after/*.vim'
 32     call s:rtp_rm(g:bundle_dir)
 33   endfor
 34   call s:rtp_add_defaults()
 35 endf

[raghur]

@starcraftman yes - that's seems to have fixed the sparkup issue! My bad for not RTFMing windows section.

[jdevera]

weird weird weird.

@starcraftman when you ran it in linux, is it possible that the small delta you say was the installer.vim file?

Is there something special about the plugins that are not loading?

[starcraftman]

@jdevera It is strange. I retested on Linux with this config and you are correct, the small delta was just scripts read in for functions the installer uses. I guess this is purely a Windows issue for some reason. I'll look into some remedy other than invoking require bundles...

[starcraftman]

Well I haven't really found anything else out. I'm documenting the temporary fix with require for now. Though it doesn't look great. Info is in the FAQ under Windows.

[FlorinPopaCodes]

I'm experiencing the same issue as described above, but adding call vundle#config#require(g:bundles) fixes it. Had problems with editorconfig only being loaded after a PluginInstall or PluginUpdate.

I'm on ubuntu 13.10 with https://github.com/astrails/dotvim + https://gist.github.com/icehero/c23bbd4380efb6bf8feb with the latest versions installed.

[starcraftman]

@icehero I just had a quick look at your stuff, this seems to be part of a larger config that I'm not going to go through. I assume you have the required rtp/plugin lines for gmarik/vundle sourced before this (see the quickstart)?

Do you turn off/on the filetype plugin to make sure these Bundles are sourced after these lines execute?
i.e. after that snippet should come

filetype off    " if it was on
filetype plugin indent on    " required

[FlorinPopaCodes]

@starcraftman sorry for the high-jacking of this issue. I was under the impression that I could add some Bundles without changing the main config. After adding my extra Bundles with the others, it started working. Thanks.

[starcraftman]

@icehero It is more of a vim limitation, you need to toggle filetype on/off as I understand it to ensure sourcing after rtp changes. You can do whatever config you want with the files, so long as you put the on/off after the last Bundle call. Personally, I just use a mega vimrc with fold markers, makes it incredibly easy to seek.

[nasenatmer]

I'd like to second that this still seems to persist although I'm not yet entirely sure that it is caused by vundle but all the information in this thread point into that direction.

Here's my MWE:

set nocompatible              " be iMproved, required
filetype off                  " required

" set the runtime path to include Vundle and initialize
set rtp+=~/.vim/bundle/Vundle.vim
call vundle#begin()
" alternatively, pass a path where Vundle should install plugins
"call vundle#begin('~/some/path/here')

" let Vundle manage Vundle, required
Plugin 'gmarik/Vundle.vim'
Plugin 'lervag/vim-latex'

" All of your Plugins must be added before the following line
call vundle#end()            " required
filetype plugin indent on    " required

Now, when I open a _tex_ file and try to use the mappings set up by _vim-latex_ such as \li to display some information on the compilation process, I get into insert mode instead of the desired information. Calling functions defined by _vim-latex_ yields errors.

@lervag wrote here that indeed it might be related to the _ftplugin_ setup which sounds a lot like #433, but even linking ~/.vim/bundle/vim-latex/{ftplugin,indent,syntax} to ~/.vim/after didn't do the trick.

As this all happened after I did a _:BundleInstall!_ just today and implemented the interface change I am strongly suspecting vundle to be the cause for this to happen.

Is there anyone else who can confirm similar oddnesses?

[lervag]

What I wrote here was this:

However, one idea comes to mind: If you look at the top part of ftplugin/tex.vim you will notice that I check for b:did_ftplugin. This is to prevent the plugin from loading twice. The same mechanism is found in the tex plugin that comes with vim, and so if the internal plugin is loaded first, then this might prevent vim-latex from being loaded.

Essentially, this boils down to a suspicion that Vundle might have introduced a bug to the order of the sourced plugins. That is, when you install a local filetype plugin, then you want the local plugin to be used instead of the internal vim plugin. This is typically ensured by making vim load the local plugin first, and then using logic like the following to prevent other filetype plugins to load.

if exists('b:did_ftplugin')
  finish
endif
let b:did_ftplugin = 1

Note, however, that I do not personally use Vundle, and so I am not able to confirm this suspicion directly myself.

Note also that the linking that @nasenatmer mentions should not work, since the entire point is that the vim-latex ftplugin should be loaded _before_, not _after_.

[lucc]

Does the plugin lervag/vim-latex even work as expected? I tried this:

mv .vim original
git clone https://github.com/lervag/vim-latex.git .vim
vim file.tex

and \li also puts me into insert mode. Can you please confirm that the plugin will work as expected if it is installed in a traditional way. (I was to lazy to dig into the plugin really deep)

[lervag]

Yes, the plugin works as expected. But the plugin is not enabled by default. You need to put

let g:latex_enabled = 1

in your vimrc file.

[lucc]

@nasenatmer please retry with your minimal vimrc and the comment from @lervag.

[nasenatmer]

Alright, I just did the whole interface change and update from gmarik/vundle to gmarik/Vundle.vim on my private laptop, too (when I reported it yesterday I was experiencing iht issue on my work pc) and have exactly the same behaviour. Just as an aside

The following MWE still produces the same behaviour as described above:

set nocompatible              " be iMproved, required
filetype off                  " required

" set the runtime path to include Vundle and initialize
set rtp+=~/.vim/bundle/Vundle.vim
call vundle#begin()
" alternatively, pass a path where Vundle should install plugins
"call vundle#begin('~/some/path/here')

" let Vundle manage Vundle, required
Plugin 'gmarik/Vundle.vim'
Plugin 'lervag/vim-latex'

" All of your Plugins must be added before the following line
call vundle#end()            " required
filetype plugin indent on    " required

let g:latex_enabled = 1

However, if I remove the following lines from vim-latex' ftplugin/tex.vim it actually works:

if exists('b:did_ftplugin')
  finish
endif

So is there any way to change the order in which local plugins are loaded by vundle?

[lervag]

Another aside: Everything works exactly as it should with neobundle, which works in almost the same way as Vundle.

[jdevera]

Hey! you people are providing awesome leads! I think this might have to do with this change: 1736243c0e

By putting the default rtp directories first, all guard variables are set when the user added stuff comes in.

@starcraftman if we only move the first directory in default rtp to the front, I think we fix this and also keep the other issues that led to that change fixed. What do you think?

[Olical]

Yet another example for you guys, but I think you've worked it out. I'm using vim-javascript in my bundles and I have to remove the finish statement to get the syntax changes to work. vim-javascript/syntax/javascript.vim, line 10.

[jdevera]

Hi, those of you who are affected by this, can you try a possible fix I've pushed in a branch?

You'd have to _cd_ into your Vundle directory: ~/.vim/bundles/vundle or ~/.vim/bundles/Vundle.vim, and run this in there:

git fetch origin
git co bug/rtp_order_reloaded

Then just run Vim and let me know if the problem has disappeared.

[Olical]

Just tried it on my Linux box (I was running on my work Mac before). On master: Exact same result as the Mac, as expected. After swapping branches it worked perfectly. This was using the JavaScript bundle I mentioned before.

[jdevera]

ok cool! thanks @Wolfy87

[jdevera]

@raghur can you please also do the test and see if it solves your problem?

[nasenatmer]

Confirmed, checking out your branch solves the issue!

[starcraftman]

@jdevera Little late to the party. So, it was the change to rtp. Interesting.

Your fix only puts the first directory, so are we going to simply ignore all other dirs or was that a quick patch to see if that fixed it? Should we just shunt rest of the default dirs to end of the rtp?

[jdevera]

I think the only thing we should do is what my patch does, I intended it as the solution. That is, we take just the first directory, assume this is the one in the user's home directory, and leave everything else as it is. It should solve all present and past problems and if it creates new problems, we can see from the issues that will get logged.

[raghur]

@jdevera confirmed - just switched to the bugfix branch on w7x64, removed the earlier workaround and all plugins seem to load correctly!

[denten]

Having the same problem when changing from call vundle#rc() to call vundle#begin(). Airline stops loading. Reverting back to call vundle#rc() fixes things again.

[dileepkr]

I had to put the Vundle statements in .vimrc not .gvimrc .
This fixed my issue.