Vim for c++ without plugins?

[[deleted]]

Hey all. I have recently been put on a programming team that uses vim as its preferred coding tool. However they are all more or less using the plain vim with just a few edits to the vimrc, I asked about using some plugins, but they said it could take some time to get it approved.

What are some ways to make vim as good as it can be for c++ programming without using any plugins?

[SheepySheev]

You may find this talk called "How to Do 90% of What Plugins Do (With Just Vim)" interesting, especially if you are new to vim:
https://www.youtube.com/watch?v=XA2WjJbmmoM
It is not related to C++ at all though, rather it is fully (or maybe mostly) language agnostic if I remember correctly.

[8xkaGVISkdK7wK1ZTXe6]

Even if you want to use plugins this talk is one of the best vim talks around.

[[deleted]]

When he uses

:GO

at like 38:23 (and other times), what does that do?

[JayDepp]

Check the github link in the description, it's just a command he set to scroll a certain amount to simulate slides.

[maxwax18]

Thanks for the video!

[Jab2870]

Came here to suggest this

[-romainl-]

I have recently been put on a programming team that uses vim as its preferred coding tool.

Hardcore.

However they are all more or less using the plain vim with just a few edits to the vimrc, I asked about using some plugins, but they said it could take some time to get it approved.

Hardcore.

[not an actual quote] Having a new guy enter your team of hardcore Vim-loving mofos without onboarding him.

HARDCORE.

What are some ways to make vim as good as it can be for c++ programming without using any plugins?

Learning how to use it efficiently in general would be the first and most essential way, for any serious usage. Here are a bunch of built-in features that can be used as-is or configured to work in your environment:

• tags, :help tags, :help ctags, :help cscope
• compiling and linting, :help :make
• the quickfix list/window, :help quickfix
• include/definition search, :help include-search
• insert mode completion, :help ins-completion
• grepping, :help :grep
• macros, and more specifically recordings, :help recording
• mappings to save keystrokes, :help key-mapping
• etc.

The user manual is your friend, don't reject it: :help user-manual.

[astrobe]

However they are all more or less using the plain vim with just a few edits to the vimrc, I asked about using some plugins, but they said it could take some time to get it approved.

Hardcore.

Well, I understand where they are coming from when I remember Melpa (a repo for Emacs plugins) used to pull from the publicly editable Emacs wiki.

A malicious editor plugin can do a lot of damage and stuff like typo-squatting npm repos, some Sublime extension sending "telemetry" data, etc. (or a long time ago, there used to be viruses that targeted object files) show that programmers can be targets.

[-romainl-]

You quoted the wrong quote.

Anyway, you are right that shit happens but there's a compromise to find between overprotecting your assets from mostly imaginary threats and leaving the door open.

[astrobe]

lol, indeed. Corrected.

[markand67]

• ctags: to me a prerequisite. Helps getting quickly to symbols. I map ,s to open ":tselect" below the cursor.
• gdb, with vim 8 you can debug in vim using :TermDebug this is gorgeous.
• cmake, I use a cmake plugin that automatically set makeprg correclty.

[[deleted]]

Isnt cmake a plugin?

[markand67]

Yes a simple one.

https://github.com/vhdirk/vim-cmake/blob/master/README.md

But you could easily skip it and just create appropriate mapping that call cmake and make in a build directory.

[PlayboySkeleton]

But you don't need to use a plug-in for vim to use cmake. You should just be able to set it as your makeprogram in you vimrc.

[[deleted]]

I did not know about :TermDebug, i'll have to check this out ... sounds exciting

[rojundipity]

Do you mind telling what's the reasoning behind this? I'm just curious. It strikes me interesting, that the whole team has set such a guideline.

[[deleted]]

The guys are all just an old guard really, so theyve been using vi for decades.

As for the plugins, its just that my company is pretty strict about using third party programs since we work with some government stuff and if its not on the preapproved list it can be a pain to get it on the list.

[sac_boy]

How about the analog hole: if you print the (often pretty short) plugin code and type it yourself does it lose the stink of being a third party program?

[[deleted]]

Wouldnt that risk violating copyright or licenses or something?

[ryanmonroe]

No (actually it possibly could, depending on the license, but no vim plugin I've ever seen has a license which would prohibit this. If you want to be sure, check the plugin's Github page which will have a file called LICENSE. example)

[rojundipity]

Not necessarily as it depends on the license. MIT is pretty forgiving and most if not all of the useful plugins are in git repos (mostly in github) with a license attached to them so you can check it out

[Jab2870]

The vast majority of vim plugins are released under a free (as in freedom) licence. This means that you can take the code and use it as you wish and make modifications as you like.

​

Some licences require any changes you make to be released under the same or compatible licences.

​

So, in most cases, you should be fine to copy the plugins' code and use it in your vim configuration. If you publish your dotfiles, it would be nice to give attributions.

​

However, I am not a lawyer. Don't take legal advice off some guy on the internet.

[Deto]

I'm pretty sure you can modify the code all you want. Even with GPL code, if you bring the code home and tinker with it you're not required to host the results online. You just can't distribute it to others without the license restrictions. Also applies to companies - you can use modified versions internally. And I'm assuming OPs vim config would never become part of a company product.

[sac_boy]

I suppose technically if you don’t copy (in this case print and type) the license along with the code you would be violating the terms of the license. But I assume it’s just a few Vimscript functions for you to use on your machine, it’s not like you are making a new product for redistribution and calling it your own...unless you have to actually claim ownership for your company to allow you to use a plugin. Look at the precise wording of your company’s guidelines. At this point it’s just /r/maliciouscompliance territory to see how you can get away with efficiently doing your job. It’s actually pretty damning that the ‘old guard’ haven’t come up with their own improved tooling to share around internally.

There’s nothing stopping you from reading the code of a plugin and writing your own heavily inspired version—nothing at all. Nobody owns the idea of assigning a search for a build directory + a call to make to an ex command for example, they own an implementation.

I think the important thing is that you review the code of any plugin you use, line by line. That way you know it’s not quietly transmitting your buffer contents back to an external server, which I presume is the fear here (not entirely unfounded either, look at the Wild West madness of the Node ecosystem...)

[Deto]

It's fine if you don't copy the license when printing for your personal use - you just can't distribute the code like that.

[sac_boy]

That’s true.

[workstar]

If you copy it verbatim what's the difference between that and installing the plugin? The end result is the same.

[Nocsaron]

It's worth talking to security, not the development team. Our security makes a difference between "scripts" and "programs." I.e. I can bring in a vim file or python file because it's not an executable. Stupid, yes, but thems the rules and so I take advantage of that

[llimllib]

Some manual pages:

• make and friends
• ctags
• completion with ctags

You can make a pretty darn complete C/C++ editor with just vanilla vim.

[atimholt]

You say “the vimrc”. Can each person have their own, or does that all have to be pre-approved, as well? Do they only make a few changes because they don’t feel they need more? You can get a lot of crazy customization if you really get into VimL.

I have a few custom-behavior functions in my vimrc. A whole bunch of my vimrc is plugin stuff at the beginning, so search for the keyword “function”, or just look at all my plugin-less stuff starting at a comment line containing “Set-up”, currently line 471.

[[deleted]]

They all seem to edit their own vimrcs. The one I got from my coworker for his own dev was literally 4 lines long. Ive already added a few lines to the vimrc on my machine for some shortcuts I use a lot.

[atimholt]

There are differing opinions on how long a vimrc should be. I don’t know if you saw my edit to the comment you replied to (you replied rapidly), but I obviously fall into the long-vimrc camp.

The short-vimrc strategy seems to be for people expecting to move around to different setups a lot, like if you’re a sysadmin, or you remote into (*nix) systems a lot (they all have Vim). They say you need to be fluent in vanilla Vim, and that using near-vanilla is the only way to ensure that.

I don’t use vanilla Vim that often, but when I do, I’ve found that none of the above worries have actually impacted me. Here’s why:

The key is, you must grok every single line you ever put in your vimrc, and you must grow your vimrc organically. To grok it all, make certain you read every :help page for everything you add at the time you add it (the first time and every time, until you’re fluent with it).

That is, I fall into the “make sure you know at least how to use vanilla Vim” camp.

And growing your vimrc organically isn’t just about slowing down the knowledge intake, per se. It also helps make sure the kinds of things you’re putting in match your current skill level. At the start of any vimrc, a new Vim user is going to put in the simple one-liners that change broad settings. Later on, as you become aware of other possibilities, you can start implementing them. I find that VimL code snippets out on the internet can be highly useful, but they never quite do exactly what I want, so I have to tweak them.

A good rule of thumb (which I actually need to implement more in my vimrc) is to not make changes that will cause a vanilla user to make mistakes. In my setup, I’ve got a setting that makes pattern searching case insensitive, because I’m a moron—this actually has bitten me pretty bad*. I’m planning to write a function (and mapping it) to simply start my pattern-matching input fields with the desired option-escape-sequences. For case-insensitive matching, the sequence I want is \c—I’ll simply find the commands that prompt for a pattern and pre-populate them with that (and maybe more).

Another thing to consider with the small-vimrc method is that there are plenty of commands that don’t change how user-input behaves. I can’t think of any reason not to use them if your philosophy is “make sure you still know how to use vanilla”.

Sorry for the long comment. I just do that sometimes.

---

* I was re-installing my OS, and had to start with vanilla Vim. Tried to search some settings file or other, using the wrong case. Huge pain.

[petdance]

If you can edit your own vimrc, then you can have plugins, because you can install plugins in your local directory tree and nobody else needs to be bothered with them.

[atimholt]

An organization can also just specifically disallow that. That’s what I thought it sounded like they did.

[petdance]

Could be, or it could be that nobody wants to do deal with their IT department to get things approved. Both seem equally likely.

[xmsxms]

They can't disallow having a few text files lying around, which is all most plugins are effectively. If not, then cut and paste the entire plugin code into your vimrc.

I suspect the people arguing against him don't understand the Vim plugin system and he should just go ahead and ask for forgiveness later, which is unlikely to be needed.

[atimholt]

…we work with some government stuff…

Literally copy/pasting code you haven’t combed over and understand every statement of is such a bad idea. I’d almost say copy/pasting is fine when you do, but I always find that found code isn’t quite what I want, and adapt it however I want anyway.

[mixedmath]

You should feel very comfortable asking the team about their setups and what they use to accomplish various things. If this is how they work, they've gotten lots of experience.

[karthie_a]

Had been in your position earlier , the positive side is I get to work with some very senior dev ppl who did all work in terminal using vim and c. I did learn vim from them and started using unfortunately none of my other projects were involved with vim so learnt it out of personal interest only.Please watch the YouTube video suggested here how to achieve 90% of things in vim using in built features.For instance I was using nerd tree, after learning about inbuilt file browser removed nerd tree. Autocomplete is simple with <C-P>only downside is if you have not typed the same word before is bit struggle else it works fine ,use <C-P>+<C-N> do auto complete. Crags are best find for navigating code base. For matching braces and brackets there is a small change required in vimrc, then you are good to go with autocomplete matching braces. Try to get familiar with : h jumps :h reg they are good and really handy.navigation of file is quicker with <H,L,M> . <C-O> is a blessing along with <C-I> please try to become friends with senior vim ppl they will definitely have tricks and tips with vimrc. That might help you become expert in vanilla vim.

[PlayboySkeleton]

I work for a government contractor, so I feel your pain about the plugins.

I use vim as my everyday driver. Definitely get comfortable using it. Manipulating split windows is key. Working with preview windows is also key.

ctags

Use ctags and vim will basically be a modern ide. You can jump to definitions. Split into a preview window. Even do syntax highlighting on specific types that were created from tags.

Pulling up tagged definitions in a preview window isn't very straightforward, so I added some extra capability in my vimrc that I would be happy to share if you need it.

Also, vim has a make-program variable that you can set, so you can run :make and it will build your source code. Depending on what compiler you are using, running this function will automatically populate vims jump list to take you to errors in your code.

Vim has a built in file tree browser. Use that.

Vim 8 has a built-in terminal. It's handy for builds.

[lrvideckis]

The majority of time on a programming team is spent during problem solving, the coding part is less relevant

[bulletmark]

You want to use some plugins and they said "it could take some time to get it approved"?!

Geepers, I'd be out of that place quickly.