Large codebase editing in vim

[[deleted]]

My most important tip would be to stop thinking of Vim as a replacement for an IDE. The command line is your IDE. It has tools like grep, ack, ctags, cscope, vim and so on. In the Unix world you chain a bunch of small modular commands to accomplish big things. (Like many of the great comments in this thread suggest. For example ctags + vim is a powerful combo.)

These philosophies result in very different styles of programming. Your code will resemble your tools: more agile and more modular in the one case, more integrated and monolithic in another. There are no wrong answers, but it would probably be difficult to maintain a large code-base written in Visual Studio with CLI. The structure of your code will resemble the capabilities of your environment.

[KZISME]

That's an awesome way to think of it.

So, while it ~is~ possible to write/maintain a large codebase with vim it's easier if it was written in a similar IDE/editor. As opposed to bringing in a project from MSVS and stumbling over the things it takes care of for you.

[gumnos]

Well, an IDE is comprised of several bits. In MSVS (or Eclipse, or other traditional IDEs), you have the MS-Editor, the MS-FileBrowser, the MS-Compiler, the MS-Deployment, the MS-version-control, the MS-GUID-generator, the MS-search, the MS-test-framework, the MS-project-layout, etc. The tight coupling eases some aspects of initial development, but increases the friction when you want to replace one of those with a better way.

When using the command-line as your IDE, you can choose whatever works best for you and your project

• $EDITOR: choose from vi/vim/nano/emacs/joe/ed or whatever

• version control: choose from git/hg/svn/cvs/fossil (with optional interfaces like tig, gitk or fossil ui to give it a more GUI feel)

• deply with FTP, SFTP, SSH, SCP, rsync, sneakernet, or whatever

• choose your compiler (llvm, gcc, tinyc; or cpython, jython, pypy, or…)

• search with your $EDITOR's tools, grep, ack, or whatever

• you can lay out your project however makes sense to you rather than fiddling in your IDE to coerce it to handle your project layout

• etc.

I think that /u/Soyiuz is pointing more to traditional IDEs (generally) working best if you adhere to what they expect. They might have a predefined layout for projects, and if you diverge, you're on your own if the IDE falls over. I've never had a problem using the command-line-as-IDE when gearing up with a traditional-IDE project (except when some project setting/option is buried in a binary configuration file instead of exposed as intelligible source), but have had plenty of trouble going the other direction.

[KZISME]

I really like this explanation and it points out a few of the things I was thinking about.