I use gVim with Janus. Fantastic. Now I want to improve and change this environment, so it is more suited for PHP (Drupal) development.
I prefer to do this in an entirely separated environment. Many plugins and vimrc entries will problably be duplicated across these environment, but a lot will need slight modification or are unneccesary in one of both environments. E.g. most of rails.vim is not needed in the drupal vim environment. While Xdebug setup is only usefull for PHP development. There will probably be more such environments: like writing latex, Blogging, presentations etceteras.
I don't mind running a command or script before starting to develop, in order to switch between Rails, Drupal and other environments.
I have looked at pathogen, but that seems to only allow "install plugins and runtime files in their own private directories. ", while I am looking for a way to have the plugins and runtime files bundled into separate environments and directories.
As such, I would like to fork Janus and start modify-ing for Drupal development.
The simplest solution I see, is to introduce different .vim.somename directories with their own content and switch a symlink: rm ~/.vim && ln -s ~/.vim.somename ~/.vim.
Will this work with Vim? Will this work with Janus? Is there a better approach?
See :help initialization. You can use the -u switch to have different vimrcs. In those vimrcs you can set different runtimepaths (:help 'rtp').
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.
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.
I'm a VIM noob, and have revisited it time and again, and I'm hoping to actually stick with it this time. Primarily I'm programming in TextMate with Ruby on Rails. On advice from someone, I have installed Janus (https://github.com/carlhuda/janus) and its helping a lot. But one thing I miss is having a "project" so that I can easily get back into a project quickly.
I want to be able to start a copy of macvim, pointing it to a file, or giving it a command, to load a project back to where I last left it. This means:
CD to the root of the project
Set back up any tabs / splits I had set, at their same locations
Reopen the files I was working on last.
I'm going to explore Conque Shell today (http://code.google.com/p/conque/) and if that works, I would want those shells to also reload and fire off their startup commands. (CD to the project root, fire up the rails server, tail a log, etc.)
Suggestions? I'm looking to streamline my process so that I can just click a shortcut or run a command and after a few seconds be staring at my dev environment right where I left it last.
Bonus: I often use windows too, so being able to do the same in GVim would be great as well.
Thanks for your help
You may want to check out Vim's built-in ability to create a restore sessions. These allow you to save pretty much everything you have setup including cwd, folds, splits, buffers, vars etc. See :help :mksession.
Here are two plugins that help with saving and restoring sessions:
sessionman: http://www.vim.org/scripts/script.php?script_id=2010
session.vim: http://www.vim.org/scripts/script.php?script_id=3150
You might also want to check out the project plugin: http://www.vim.org/scripts/script.php?script_id=69
I too have heard good things about rails.vim.
For Rails developer, there is a well-known plugin by Tim Pope named rails.vim.
Once you are at the root of a rails project (You can change Vim current directory with :cd /path/to/project/root ), rails.vim provides quick way to access your file like :
:Rcontroller file
:Rview file
:Rstylesheet file
They are other options to refactor using partials. Install it and type :help rails.txt. There is plenty of nice features like that. It is really useful to speed up access to your project files.
You can probably combine it with session.vim which provides a way to restore your previous session automatically.
If you don't want to type the path of your project, one possible solution, is to add at the end of your .vimrc the following code :
if isdirectory("~/workspace/project1")
cd ~/workspace/project1
endif
This way you always start Vim into your current workspace. Obviously if you need to switch to another directory you have to manually edit your .vimrc... which is kinda sub optimal.
Terminitor (a Ruby Gem) won't specifically solve your vim "project" goal, but it will solve the rest of your problems. You can setup your terminal windows and then execute a command to capture the terminal positions and sizes, edit the configuration to add any other commands (in Ruby) that you want executed and this will allow you to restore your environment.
Both of these plugins require Vim to be compiled with Ruby support, need to be compiled themselves using the same version of Ruby, etc. Is there a plugin which does the same job, but doesn't require installation other than dropping it into vimfiles directory?
UPDATE: These plugins allow to open files/buffers by typing characters which appear in their path, not necessarily in a row. I.e. if your directory has files
foo/bar.txt
foo/baz.vim
zee.c
you can type
,t f
and only two matching files are shown; after you add r, only one file is left and it can be opened by pressing <Return>.
Using the latest fuzzyfinder vim plugin you can use
:FufCoverageFile
to mimic the global search features of fuzzyfinder_textmate and Command-T. No ruby needed.
Need also to have vim >= 7.2
I used LustyExplorer which provides similar functionality to the plugins you mention. Unfortunately it also requires ruby.
Later I started using LycosaExplorer which is based on LustyExplorer but uses python instead of ruby. I prefer this one to LustyExplorer because I cannot compile vim against ruby in windows and with python I can do it fine.
Recently I started using ctrlp.vim which also allows you to do something similar to what you request and doesn't require external depedencies (ruby or python). It seems to me that it is slower than LycosaExplorer on folders with a large number of files.
There are a few plugins in this same thematics. fuzzyfinder may be the most ergonomic though.
I've listed some of them on the description page of searchInRuntime (that also helps opening files)
HTH.
ctrlp is a good one. It's used a lot, if for no other reason than it's in janus.vim
If you don't mind python dependency， LeaderF is a good choice. The performance on large project appears very well compared with some similar plugins.
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