Using Vim for C++ Development
My first advice for anyone who wants to use Vim for C++ development would be - don&#x27;t. I&#x27;ve used exclusively Vim for over 10 years and it&#x27;s too comfortable to switch to anything else, so I&#x27;m losing out on a lot of productivity, or at least that&#x27;s what my colleagues, who have never used Vim, claim.<p>Pithy claims aside, it has been an interesting journey actually using Vim for producing C++ code for large projects. There&#x27;s a strong DIY element and you end up with a setup that&#x27;s much more customised than a vanilla IDE - on the one hand giving you a certain degree of comfort in your work, but on the other a lot of what you do is unportable to other people. The language server protocol has been a pretty good development, I&#x27;m keeping an eye on what comes out of those efforts, though I&#x27;m not using one personally right now.<p>My current setup consists mainly of exuberant-ctags for static indexing, YouCompleteMe for intellisense and simple navigation, rtags for rich search and light refactoring and fzf for searching. As to why I ended up settling on these plugins:<p>- ctags:<p>Absolutely essential. Yes, a full semantic index straight from the compiler is better, but ctags is more than good enough for just telling you &quot;where is this defined&quot;. When paired with fzf, you can type part of the tag, space, part of the directory and you&#x27;ll get all tags in that directory. That&#x27;s due to fzf doing super simple substring matching in the TAGS file&#x27;s lines based on your query, there&#x27;s nothing smart going on here. This tool is also very good when you are developing multiplatform software, because the compiler cannot see all places where a function or class is defined, since you have one definition per platform. Technically being able to query a plethora of language servers, one for each configuration, would be ideal, but we&#x27;re not there yet, and such a setup sounds way too fragile for my taste.<p>- YouCompleteMe:<p>Aside from C++, it provides amazing completion support for many other languages. It can even deal with java project files, if the readme is to be believed. Other than for C++, I mainly use it for python. It&#x27;s also good in plaintext files for completing words and file paths. I really love its substring matcher, just type gTFBT to get &quot;getTheFooBarThing&quot;. Downsides: 1. if your build system cannot produce a compile_commands.json file, you will need to write some python code to specify compilation flags; 2. compiles each file individually, so if some of your headers aren&#x27;t freestanding, you&#x27;ll get spurious errors when editing them.<p>- rtags:<p>Basically a language server from before the LSP protocol existed. Mainly developed for Emacs, but the Vim integration is good enough. Continuously indexes your source based on a compile_commands.json file. It can show you who calls a function or uses a variable, class hierarchies, virtual method overloads and more. I&#x27;ve seen it get confused if you jump branches and require you to delete and recreate the index, but I haven&#x27;t experienced that lately.<p>Apart from those I use a bunch of standard productivity plugins like unimpaired, surround, nerdtree, etc. etc. Vim 8&#x27;s gdb integration has been very welcome, too. I struggled to find a good interface to gdb previously, as everything seems to want to be Visual Studio and give you a restricted clicky interface, whereas I just wanted the current vim buffer to be synchronised with the instruction pointer and to write gdb commands directly.<p>I don&#x27;t feel like I&#x27;m substantially slower in Vim than my colleagues in other editors and IDEs. Colleagues across the company use Vim, Emacs, VSCode, QtCreator, and Code::Blocks. The Windows developers are all on Visual Studio naturally. I haven&#x27;t noticed being slower than any of them. The above plugins are enough for the odd rename-refactor I have to do, and anything more substantial is so infrequent, that doing it manually doesn&#x27;t really have an impact. Also, developing on Linux, I always feel like any graphical application will just disintegrate or cause an unrecoverable freeze in the graphics driver at any random keystroke.<p>Back in the day I had to make do with just ctags, cscope and debugging straight from the commandline, lol. I do believe that Stallman&#x27;s refusal to allow easily plugging into GCC&#x27;s AST, like one can just use clang for indexing, held back C++ development tools on the Linux platform significantly. Eclipse&#x27;s CDT, KDevelop, Anjuta, Code::Blocks, NetBeans, etc. - they all suffered from having to write their own C++ indexers that were always inferior to getting semantic information straight from the compiler. I&#x27;m extremely grateful to the open-source community for the continuing work on development tools, and try to donate where I can. Watching the development tools landscape change over the years has been interesting - things don&#x27;t so much improve, as they evolve chaotically with an overall trend towards improvement. Like anything else on this platform. So far many IDEs have come and gone, but Vim is eternal.<p>I will say that using Vim is entirely up to your taste, it doesn&#x27;t seem to be substantially faster or slower than an IDE, so use what you like. It is much cheaper than Qt Creator or CLion (AFAIK for both you need a license to develop commercial software), so that might be a factor for you. Companies tend to have a big Windows development team, with a few Linux developers, so they buy bulk Visual Studio licenses and individual Linux IDE licenses, making the latter end up costing more per developer.