If I understand it correctly, with pathogen it makes things easy because all you have to do to install/uninstall plugins is place or remove the plugin from a certain directory.
But isn't this what the plugin directory is for? How is it any better?
A plugin can be a single plugin_name.vim file that you toss into ~/.vim/plugin/. If every plugins were single files we wouldn't "need" any plugin management solutions.
But most plugins are actually collections of files that need to be placed in certain directories like ~/.vim/autoload/, ~/.vim/after/, ~/.vim/doc/ and so on. This has been considered "messy" for a while and Pathogen is one of many answers to this problem:
Vimball :help vimball
Vundle
VAM
VAM
Unbundle
possibly others…
If you don't think that it's a problem then you obviously don't need a solution (pathogen or whatever).
I think that it's a problem (I like my things well organized), Pathogen is the first solution I came across and it served me well.
It's better because you can store your plugin in isolation in the ~/.vim/bundle directory. That makes easier for you to have all your configuration directory under a version control system. Take a look at my vimfiles for example.
All the plugins I use are stored as a git submodule and this makes updates easy to handle. Furthermore, if you want to remove a plugin it's just a matter of removing the relative directory in the bundle one.
Related
I'd like to build a small set of vimscript libraries, however, it seems that the only way to use them would be to load them all globally into vim.
Furthermore, it means that if i wanted to share a single script that depends on those, i'd have to share to them all, which sounds tiresome.
What i was hoping for is some common.js and webpack style approach to vimscript,
does such a thing exist. Something that:
Resolves dependencies
Allows for vimscript files to be "bundled" together into one file.
Everything that i found, winds up being a plugin manager, rather than a plugin build tool.
Do such things exist?
The situation so far, up to Vim 8.
There is no script isolation. When a script is loaded, it's globally. The script can hide variables and functions, but that's all.
Sharing/exporting a function is quite easy: we drop it in an autoload plugin, and we just have to use that function named dirrelatativeto_rtp#subdir#suddir...#scriptname#funcname(). If the script scriptname.vim is installed in dirrelatativeto_rtp/subdir/subdir somewhere in a directory registered in 'runtimepath', it'll get loaded automatically.
Regarding commands, abbreviations, mappings... they are meant to be defined in plugin files, or ftplugin files -- other approaches are possible when we want submodes. Also we cannot use them naively from an autoload plugin or when a script is being loaded -- we'll have to explicitly use :runtime to load the script where this command/mapping/... is defined (as we'd do an import in Python).
Yet, like with Python, scripts aren't installed automagically on our system. It's still up to us to trigger manually the installation of scripts.
We can decide to have library plugins and other plugins that depend on these libraries. But, we need either to tell the end-user everything that must be installed manually, or kindly tell him/her to stop using a plugin manager that don't understand dependencies.
This has been a personal rant of mine for years, the trendy plugin managers don't understand dependencies. There are so far only two plugin managers that do so:
Vim-Addon-Manager (aka VAM): it relies on a central repository (vim-pi) to install a plugin (and its dependencies) with just its name (e.g. :InstallAddon fugitive, :InstallAddon lh-cpp). Unfortunately the central repository is no longer maintained and we can't register new names. Fortunately, we can always install anything with :InstallAddon github:{N}/{repo}. Other functions are available for installing from the .vimrc.
and vim-flavor which is written in ruby, and which install plugins as Vim 8 packages.
Both have their own syntax to declare dependencies. Unlike VAM, we can specify constraints on plugin versions with vim-flavor.
Last thing, if we don't want to distribute all files, we can organize them as several "plugins". But beware of cyclic dependencies. And be kind to end users that are using these trendy plugins managers that don't understand dependencies as they'll need to explicitly install many "plugins"
Starting from Vim 9
We can start to isolate imported plugins in the sense that two plugins can define a function or a command with a same name. Again, this feature seems to mimic Python way of doing things.
However, I expect global stuff like autocommands to continue to operate globally. For instance: I don't see how we could have two template expander plugins running concurrently.
Vim 9 new scripting language won't change anything to the installation of plugins we depend on.
Disclaimer: It has been almost 2 decades now that I've been maintaining my plugins as a bunch of interdependent plugins, organized around a few library plugins, as I don't like to duplicate a same thing several times. In my rant about dependencies & co, I explore quickly other alternative approaches available to us.
Back to the bundling/packaging question (EDIT)
We have ways to package files together.
We can always manually define plugins: put files together in a directory tree, play with git and so on.
We can define tarballs.
We can also define vimballs. Vimballs are a quite old solution for installable archives: files are put in their right directory and documentation tags are produced. There are ways to produce vimballs. I continue to maintain scripts that help producing them for all my plugins. But in all honesty, this is not what people expect to have nowadays to install plugins. I just keep them around in case I release new versions of my plugins on vim.org.
In any case, neither of these solutions end up defining one single file we put somewhere in our ~/.vim/ directory. And I think we will never have something like that because:
Isolation is not perfect. Even with Vim 9 new scripting language: I don't see how we could correctly handle duplication of autocommands. If a same file, that defines autocommands, is duplicated in different versions in several distributed "plugins" I don't see how Vim could handle that correctly.
Vim expects different files in different places: ftplugins, plugins (the original meaning in vim context, not the set of files that could be installed together), syntax files, fold plugins, indent plugins, colorschemes, langmaps, and so on. Vim architecture does not expect everything in a single file.
For these reasons, I cannot see how we could have build systems that build single files ready to be distributed. It could work in some cases (pure collections of functions and "classes"), but not in the general case.
I'm trying to get better with Vim at Ubuntu 14.04, but I struggle to understand it's structure. I've been Googling around for quite some time, but this questions I haven't gotten answered anywhere.
I'm trying to install some plugins and make a good .vimrc-file for myself, in the future. But when I have to install plugins, then the Readme-files tell me, to put the files in the 'plugin'-directory in the vim-folder. But I've discovered that I have two vim-folders:
- One in /etc/vim/
- and one in ~/.vim/
I tried putting the plugin in each folder, and it worked, in the latter one. But I don't understand why. Can anyone explain it?
And it's the same thing for the vimrc-file. If I run a :version in vim, then I get, that there's a vimrc-file here /etc/vim/vimrc and theres one here ~/.vimrc . Now - why is one hidden and one is not? I'm a Windows-kid originally, and if confuses me, because it looks like that the format is different, from one file to the next. But mainly; where is it good manners to insert the custom changes to the vimrc-file? For the system-vimrc file, or for the user I'm using?
Files and directories under /etc/vim/ make up Vim's system-wide runtime files.
You must never touch them.
because they will be overwritten next time you update Vim,
because messing with them puts Vim in an unstable state,
because you need to escalate privileges.
All your configuration must happen in your $HOME:
your settings/mappings go into ~/.vimrc,
your plugins and colorschemes and anything you download from third parties go into ~/.vim/.
That said, most (all?) plugins clearly use ~/.vim and ~/.vimrc or their $HOME variants in their install instructions. If they don't, complain to their author.
I just start using vundle, I'm curious that where should I place my
language(may python, ruby, php) syntax/indentation configuration file.
When I put these configuration file in the normal place .vim/syntax,
.vim/indent, they worked, but they didn't work when I put them under .vim/bundle.
I wondering is it suppose to be in somewhere under .vim/bundle if I want vundle help me to manage these configuration scripts?
Thanks.
Regrads.
The best place to put your custom scripts is .vim/after.
The reason is you may always want your custom scripts take the last effect. For example, vim has default actions on python files, then the installed plugins will add more. You may not be satisfied with all them so you roll out your own, which will be the last to call in loading.
You can either version control the /after folder or whole ./vim folder.
Vundle only helps you managing your own configuration if you put it in a (Git(Hub)) repository and reference that in Vundle, just like other repositories. You still need to stick to the normal 'runtimepath' hierarchy; i.e. for a Python filetype plugin, you'd put them into ftplugin/python.vim inside your repository, and that gets installed by Vundle into ~/.vim/bundle/my-python-filetype/ftplugin/python.vim.
On the other hand, if you just maintain your own customizations on the system (without a repository), Vundle doesn't help you much, and you can just keep them in the normal location.
I posted an issue at github about this as well, but I figured this would also be a good spot to ask:
Does anyone know how to accomplish this functionality? I've been trying for the past couple of days to figure this out all to no avail aside from putting directly into my ~/.vim/ folder.
I'm trying to install the jslint ftplugin to give me error highlighting while eding javascript files. I have tried all the following combinations to try and get this ftplugin to work within the contexts of janus:
~/.janus/langs/javascript/ftplugin/jslint/
~/.janus/ftplugin/javascript/jslint/
~/.vim/janus/vim/langs/javascript/ftplugin/jslint/
~/.vim/janus/ftplugin/javascript/jslint/
All of those above fail to recognize this ftplugin. The only one that works is this:
~/.vim/ftplugin/javascript/jslint/
but that is not ideal since this is not core to janus. Any ideas on where this folder (or any other ftplugin folders for that matter) can be put so macvim to recognize this functionality?
The solution to this is to put it in
~/.janus/jslint/ftplugin/javascript/jslint.vim
Each folder inside the .janus should have the same file structure as a normal .vim folder. (So the ~/.janus/jslint folder is equivalent to .vim)
Note janus made this task really hard. Using plugin distributions like janus might lead to easy set up in the beginning but changing them or debugging them will be hard. You should set up your vim environment the way you want so that you know everything in it. This will lead to easier maintenance later on in life. And you will know how to use everything because everything was installed one at a time instead of all at once.
I want to know how do you manage your vim plugins.
As it is,
One of the biggest fun of using is that one can easily try many interesing new plugins, just download it and unzip it in under ~/.vim. But if you try too often and try too much, you might get trouble as confilct of key mapping , in compatitble script version, dpendency between different plugin .....
Then you want to remove some plugin ,kind of like rollback your vim to a sound condition. But, the rollback could be very painful . cus for some "giant" plugin, like perl-support ( it's great plugin, anyway), will consist of many vim scripts which spread in different dirctories. To remove single one giant plugin will be anoying, not too mention if you remvoe many plugin at one time.
In a word , I'm looking for good practice for managing vim plugins.
I have my vim directory in git.
All plugins that have an upstream public git repo are in ~/.vim/plugins-git/ as git submodules. My vimrc sets the runtimepath to include the directories in ~/.vim/plugin-git/ so the plugins can stay self contained and can very easily be updated to the latest git commit.
The rest of my plugins are in ~/.vim/plugin/.
One script that's out there that makes this type of setup much easier is pathogen.vim. pathogen.vim sets up all the runtimepath entries for you so you don't have to. It's worth looking into for sure. I don't use pathogen because by setting the paths explicitly in my vimrc I can quickly disable plugins if there are conflicts or incompatibilities like you mentioned.
Vundle definitely deserves a mention, as it makes vim plugin management ridiculously simple.
1. git clone https://github.com/gmarik/vundle.git ~/.vim/bundle/vundle
2. open up your vimrc
3. Add your plugins (Bundle '<link to plugin>') <-- look at the example vimrc on Vundle github page
4. :BundleInstall
I think Vundle was inspired from tpope's Pathogen plugin.
I like vim-addon-manager because it allows me to activate or deactivate a plugin by putting or removing it from the list of active plugins, which eases testing new plugins.
I versionning my vimconfig directory in github. So If I add a plugin I made a new commit. If I want remove it, I revert this commit.
After I link .vimrc in vimrc file in my directory and my .vim directory to this directory
I exclusivley install plugins via Vimballs. This way I can also keep plugins up-to-date across installations.
What I like about vimballs is that I can see directly where files came from. Otherwise I would probably something like git.
I'm working mostly on Windows, so this may differ somewhat for Linux, Unix and co. but if you help vimfiles you'll see that vim has an order of loading files. First comes the ones in $HOME directory (somewhere under Documents and Settings-Username on WinXP machines), then come the $VIM directory (your actual directory where vim resides) and so on ...
So, I have vim in a directory which consists of "stable" stuff. Whenever I wish to try out a new plugin, I put it in Documents and Settings... folder, and it gets loaded before the one in $VIM directory. That way I can easily upon not liking it, delete the new plugin. If I do like it, and it plays nicely with the ones I already have, it goes in the $VIM directory.
(this probably makes no sense the way I put it, but it works ... probably :)
Synchronizing plugins with git submodules and pathogen
The pathogen plugin makes it much easier to manage plugins in my case I use with Mercurial. To plugins vimball stile:
:usevimball ~/.vim/bundle/bundle-dir-name-here
see :h :usevimball
I personally use this mappingmanager exactly for the same reasons.
(it allows you to switch between mappings easily)
demo: http://playterm.org/r/vim-mappingmanager-plugin-1318246417
download: http://vim.sourceforge.net/scripts/script.php?script_id=3768