How do you work with large projects in VIM

Question

I have large projects with many levels of folders. Some files are named the same and depending on the folder name their function vary. For example

/admin/action1.php
/action1.php

First one would refer to administrative tasks and second one would be accessed by users. Vim gets cluttered with tabs and buffers very quickly and its getting hard to move around. Pluigins I'm using are: NERDTree CtrlP MiniBuffExplorer

I'm using gVim for Windows and plugins like YouCompleteMe are not an option.

• NerdTree - is too clumsy to move around back and forth between folders on large projects
• CtrlP - you have to know what you're looking for by typing names all the time
• MiniBuffExplorer - have ridicculus amount of files, takes way to much space on screen and its impossible to find anything
• Vim-Session - Open Save tab/windows for project

As you can see on the picture there are way to many tabs to remember witch tab correspond to witch part of the code. MiniBuffExplorer isn't helping too much.

So my question is how would you go about working with large project in VIM to keep things organized preferably by their function or section of the code. Is there a clean way to do it? Is there a way to group buffers or tabs like:

Migrations
Seeds
Admin Controllers
Admin Views
Config

Answer 1

I don't think the tools are at fault, here. It's more how you use them.

1. Tabs are not designed at all as file proxies like they are in others editors. Tabs are workspaces, allowing you to organize windows how you like them. They are the best candidates for your

   Migrations
   Seeds
   ...
   

   scenario.

   Here is one possible way to create a "Migration" tab:

   :tabnew | lcd path/to/Migration
   

   From there, all the windows you create in that tab will inherit the Migration working directory and every :e, :sp, :vs or even :vim will start from that working directory.

   Also, this will make NERDTree and netrw show the content of your local working directory by default.

   See :help seeting-tabline and :help setting-guitablabel if you want to change the name of the tab.

2. You should use CtrlP's path mode to do the matching on the whole path rather than the filename:

   fbruse
   

   would match:

   foo/bar/user
   

   but not:

   baz/vroom/user
   

   With the tab setup above, CtrlP's suggestions should be restrained to the Migration directory, making it a lot faster.

   CtrlP is not perfect though: it can be slow in large projects so make sure you read the whole documentation.

3. An "always on" list of open buffers may be a good idea when you have a small number of them but, like tabs, it obviously doesn't scale at all. It is vastly better to show the list when you actually want to switch buffers: less screen estate and brain cells wasted!

4. Be aware, though, that while it is possible to define a window-local argument list, there's AFAIK no way to define a window-local buffer list. Since the argument list always leaks into the buffer list and the buffer list is global, buffer commands will always deal with the same quantity of buffers, no matter what tab you are in. Thus limiting the general usefulness of tabs.

5. Files are not a very good metaphor for dealing with large projects: you must keep a complex symbol->file map in your head while your program is made of functions, classes, arrays, variables… not files.

   Using tags (:help tags) is a very convenient way to jump around your project:

   :tag foo
   :tag bar<Tab>
   :ptag /baz<Tab>
   

   And CtrlP's :CtrlPTags makes it almost fun.

FWIW, tag-jumping is my favorite navigation technique and I usually don't use tabs or windows.

Answer 2

You may want to take a look Vim-CtrlSpace, it is quite suitable to work on large projects. This plugin helps you deal with tabs, buffers, sessions, and more.

You can check the new demo video on YouTube.

Answer 3

I'm using gVim for Windows and plugins like YouCompleteMe are not an option.

This statement is false. Checkout my other answer on this particular topic.

Good luck.

Answer 4

Vim is not an IDE; it looks to me like you're pushing the limits of what makes sense (to open concurrently) in Vim. You can easily set up simple integrations that allow you to open a file in Vim from an IDE.

I'd suggest you use each tool where it's best: The IDE for managing and navigating through large projects, and Vim for its superior text editing capabilities!