How to use pathogen and Vundle at the same time with vim? - vim

I'm a vim newbie setting up some plugins. Some recommend installation via Vundle, others via pathogen. Is it possible to use both package managers at the same time in this circumstance? If so, is it just a matter of installing both and installing the relevant plugins according to their normal instructions, and nothing will conflict? Or do I have to do something special to make this work?

TL;DR: You don't need both; Vundle includes the Pathogen functionality (and more)
The Pathogen plugin just automatically extends your 'runtimepath' (locations where Vim searches for plugins) to include all subdirectories in ~/.vim/bundle/. This is simple, but allows to separate each plugin into a dedicated tree, making updates (e.g. via Git) and removals simpler.
Other plugins have built upon that idea and extended it with automatic download, installation, and updating, usually via some Plug foo/bar commands in your ~/.vimrc. As they need the same separation as provided by Pathogen, such implementation usually is included in them. (The core is just a one-liner, not much of a deal.)
You don't actually need any package manager; I personally use 100+ plugins without one. It's a matter of how often you use new machines with Vim (the central configuration and installation capabilities certainly make bootstrapping easier), and how often you update / try out new plugins. If you just use one or two systems, and are conservative in the number and update frequency of plugins, putting everything into ~/.vim/ might also work for you. (This is just to avoid that you're intimidated by those package managers; try them out, and use one if you like it.)

Related

Is it possible to use VSCode language-server-protocol engine along with the Vim or NeoVim?

I have tried different code-analysis engines and tools (like tern_for_vim) for Vim, but they do not provide such a great autocompletion, goto and rename functionality as in VSCode.
As I know VSCode uses language-server-protocol technology to provide IDE functionality. So here is my question:
Is it possible to use VSCode language-server-protocol engine inside the Vim or NeoVim? In other words, it is possible to provide the same good quality of IDE-like functionality as VSCode do?
I have tried javascript-typescript-langserver with deoplete.vim, but the quality of autocompletion and goto-declaration was bad.
Yes, you can use it via coc.nvim installing which is a fork of VSCode. You then apply one of its packages for a specific language eg coc-python.
This is the installation guide for coc.nvim. You then need to install the language package with this command in (Neo)Vim:
:CocInstall coc-python
You can then use the default VS Code completion engine immediately (jedi) or upgrade to what will become its successor, MSPLS:
For MSPLS run the command :CocConfig and enter this in to the file which is opened:
{
"python.jediEnabled": false
}
Then run :CocRestart
There are other other engines like coc.nvim such as YouCompleteMe. They all have small variations / tailoring for specific languages.
In theory, yes. http://langserver.org/ provides a list of editor plugins and language server implementations.
With packages like https://github.com/autozimu/LanguageClient-neovim (which is for neovim, there are others for both vim and neovim) you can use language servers in neovim.
However, some implementations are tied to the way it works within vscode (like haxe lsp), so it may be a little hard to get it working. Javascript should be better integrated, but I didn't try it myself.

what is the proper coding to add python-mode plugin to _vimrc

Would someone be kind enough to show me what exact code is needed in the _vimrc file to get the Python-mode plugin to work! Thanks! (I also read that it is out-dated) is the Jedi plugin that much better? Thanks from the VIM newbie!!!
Bob
You won't be lucky if you expect a single command in your virmrc. Turning vim into a python ide is a collection of multiple plugins you can either manage by hand or use a plugin manager like vundle. Best practice is to use your configuration along with a repository hosted for example on github using git. You can use mercurial or baazar just as well.
Walking through one of the numerous tutorials on the net will be your only chance.
For example here: https://github.com/mbrochh/vim-as-a-python-ide along with the video:
https://www.youtube.com/watch?v=YhqsjUUHj6g

How to manage the plugin managers in VIM?

I know it may sound silly, but I am curious to find out if there is a framework already in place to help VIM users manage their plugin managers.
So, I know that there are plugins like "Vundle", "Pathogen" and "Neobundle" etc. for this purpose. I have been looking in those tools for the last couple of days. And they are great. My question is, are there any higher-level scripts designed to streamline the plugin loading process utilising any of the above mentioned plugin managers.
All the "Bundle Managers" have internal functions provided for unloading and loading plugins, manipulating RTP etc. Just wanted to check before going and starting to write my own vim script.
I am mainly interested in hearing about techniques using "Neobundle". I know that "janus" is doing exactly what I am asking for. It runs it's own functions to create plugin groups and access pathogen functions. So it is a bit like a front-end for pathogen.
A nice case would be:
Let's assume that you have installed plugins "A", "B", "C" and "D" using "Neobundle", however you would like to disable plugin "B" at start-up. But then enable it later. Everytime you will have to go into your .vimrc and comment out (or in) that line which is responsible for loading plugin "B"? or run the "Neobundle" function responsible for unloading that specific plugin?
Is there a more elegant way to do this?
Thanks.
Do you have that many badly written plugins that you need not one but two freaking levels of abstraction for "managing" them?
Anyway, I don't think there is one real "super manager" because there's no such thing as a unified plugin management API in the first place and… the lack of such an API is probably the reason why there are so many variations on the same theme.
Because Pathogen was the first in that series (there are older attempts like the built-in GLVS, yeah, no one knows about it…) and stayed alone for a while, the only thing that seems to be "standard" is the bundle directory. IMO, that would make a weak starting point.
I've seen a few Pathogen frontends attempts in the past, though, so there's a "chance" that progress is coming in this field.
microbe
pandemic
There are others, browse r/vim for an hour and you will find many…
Any modern (i.e. Vim 7.x), well-written plugin should only define its mappings and commands in the plugin script, and load its functionality on-demand via the autoload mechanism. Functionality that is specific to a particular filetype should only apply there via ftplugin scripts.
Unless you do crazy stuff like having the same mappings for two then mutually exclusive plugins, I don't see a need to dynamically enable / disable plugins. Don't make things more complex than they have to be. If you really have two disjunct editing use cases, I'd rather create two separate ~/.vimrc files and aliases to use them.

Janus upgrade important functionality missing after upgrade

I just upgraded to the newest Janus and there are alot of things that I miss since December 2011 :(
For example when i entered :cd it changed to :ChangeDirectory and after changing the directory the nerdtree also updated. The same thing applies for :e which changes to :Edit
This is not anymore the case with the newest Janus.
Command-T is also not anymore available anymore. What is the easiest way to add Command-T as a plugin?
Greetings from Nepal and Thank you :)
First, what happens to you is the number one reason why using Janus (and other packages for Vim) is a terrible idea.
Instead of controlling your environment your are almost totally dependent on someone else's desiderata: because Janus's author appears to have decided against some of his previous choices and upgrading Janus is an "all or none" affair you are left in the cold with a Vim you don't understand or are not accustomed to.
You don't have to trust me but I assure you that the right way to customize Vim is to start with nothing fancy, do it yourself, little by little, without copying other people's entire vimrcs and try and install the plugins you like by yourself. Because you start from nothing and know what you add you'll never be in that kind of situation.
Second, whenever you upgrade something you owe it to yourself to review the changes before actually performing the upgrade. $ rake is easy, I must admit, but if you had taken a couple of minutes to look at Janus's Github page you would have seen that Command-T is not included anymore and replaced by CtrlP.
Third, Command-T is not and has never been a part of Janus. It's a separate project run by someone else that used to be included as a Git submodule. To install it, you need to download it separately and follow the instructions. Or add it yourself as a submodule.
Four, greetings from France, lucky bastard ;).
EDIT
To answer your comments…
I went through the TM > Vim transition myself. I started by trying to turn Vim into a TM clone but the whole idea was flawed in so many ways. Many of these flaws apply to Janus as well, IMO.
You have too many custom "mac-like" mappings that seem to make your life easier because they don't require you to learn new shortcuts. That's cool until you need to use Vim on a remote server via a terminal emulator which actively blocks many Ctrl- mappings, doesn't make the difference between Ctrl+Shift and Ctrl and don't even register the Cmd key.
If your vimrc is well organised (and it is, more or less, in Janus) your <D-> custom mappings won't be activated when not in MacVim but you'll end up with two sets of custom mappings to learn and maintain! What if Janus's author decides one day that he prefers <leader>x to jump to tab x instead of the current <D-x>/<C-x>? Are you going to unlearn the previous mappings? Are you going to modify Janus's mappings.vim to get the old mappings back?
Why not learn and use Vim's native commands instead? 2gt is easy and will likely work on every Vim you'll ever come across.
You grow accustomed and dependent to too many plugins, some of them not doing much more than native commands or even overlaping each other like the current Buffergator and CtrlP.
Customizing Vim is a great way to learn how to use it. It takes time, maybe, but the win is big.
ENDEDIT

Is there an Vim/MacVim equivalent for TextMate's Find in Project?

I was using TextMate now I am using MacVim, the only thing I miss from TextMate is the "Find in Project" functionality, is there any Vim plugin providing this functionality?
I think EasyGrep might do most of what you are looking for. It does a extension sensitive search of the current directory on down.
I use it a lot for finding things in projects.
I think Project.vim lets you search in its "project" but I never really liked the idea of having several files from different parts of my filesystem magically grouped in a virtual project.
If — like me — all the files of your project happen to be in the same "real" folder Ack.vim and EasyGrep.vim both work very well.
LustyExplorer is also very good for searching in buffers.
I've been using ack.vim to do this.
You may need to install ack beforehand unless you already have it installed. There are installation instructions on the vim-scripts page, but here's what I did (I don't use macports):
curl http://betterthangrep.com/ack-standalone > /tmp/ack
sudo mv /tmp/ack /usr/local/bin/ack
sudo chmod 0755 /usr/local/bin/ack
Which I have in a setup file for my vim configs here.
I have not used TextMate, but going through their manual, I believe one of these plugins is what you're looking for
NERD tree
Fuzzy finder
Lusty explorer
I personally use NERD tree and Fuzzy finder and they're both phenomenal! Do give them a try.
You could try Waldo.
If you like fuzzyfinder.vim you might want to have a look at Command-T as well.
The Command-T plug-in provides an
extremely fast, intuitive mechanism
for opening files and buffers with a
minimal number of keystrokes. It's
named "Command-T" because it is
inspired by the "Go to File" window
bound to Command-T in TextMate.
Here you can view some screencasts with demos of the plugin.

Resources