It seems like there's some odd caching-like behavior going on for files that I have already opened once in Vim. I have a file foo.txt that I opened, and then I change some of the settings in ~/.vim/after/ftplugin/text.vim, but those new settings do not appear in foo.txt. I can quit vim and reopen foo.txt, or reload with :e, or even :so ~/.vim/after/ftplugin/text.vim, but none of these seem to have an effect on foo.txt's settings. If I mv foo.txt bar.txt, the settings show up for bar.txt with no issues.
EDIT
It seems I can force the settings to reload for foo.txt with the following sequence:
:so ~/.vimrc:so ~/.vim/after/ftplugin/text.vim
Questions:
- Why is this necessary / why were the other settings not picked up?
- Why was sourcing
~/.vimrcnot enough? It applied settings that were directly specified in~/.vimrc, but shouldn't the ftplugins have been loaded at the linefiletype plugin indent on? Why was sourcingtext.vimafterwards necessary?
Vim runtime consists of a few hundred files, I'm not sure why you expect Vim to monitor them continuously. It doesn't. These files are loaded at some well-defined (and documented) points, that's all there is to it.
In particular there is no safe way to reload your configuration. You can do things like
:so ~/.vimrc, but unless you specifically wrote yourvimrcto take that into account, there will be drawbacks (such asautocmds piling up). If you want to be safe you have to quit Vim and start it again. That's how Vim works.Now, for
ftplugins you might get away with something like this:(use the actual filetype instead of
text). This works for simpleset fubaroptions. It works because under the hoodsetfis actually a carefully writtenautocmd. It still breaks for more complicated constructs (such asautocmds or file-scoped variables), for the same reasons:so ~/.vimrchas drawbacks.