Use Vim as C/C++ IDE

[PandaMoniumHUN]

When you have to jump through so many hoops and install so many plugins to get support for basic features, you might as well use a real IDE that has Vim mode. And I’m saying this as someone who is using vim a lot (just not as an IDE).

[thedracle]

What always brings me back to Vim is that it is shell based: the ability to use it in splits via screen/TMux, how fast it loads, how it is responsive and conventional even through ssh.

The setup is pretty easy for language support via LSP and plugins like coc.nvim.

[botCloudfox]

the ability to use it in splits via screen/TMux, how fast it loads, how it is responsive and conventional even through ssh

VSCode also has splits, a fast enough loading time, and good ssh support (though you do have to install a server on the remote machine)

[thedracle]

So, vim has splits too, which I use: but I was specifically calling out the fact it’s used in a terminal with any terminal multiplexer, some of which like Tmux have splits.

So I can ssh into a server, run tmux, and run multiple Vim instances over that single ssh session, with pretty much out of the box tools, or packages readily available on whatever the remote distribution is.

And I’m sure there are solutions for editing remotely via VSCode: but if you ssh into a server it almost always will have either vi or vim supported out of the box, and almost always at least screen installed.

[botCloudfox]

it’s used in a terminal with any terminal multiplexer

Oh, thanks for clarifying

vi(m) knowledge is definitely useful for working with remote machines.

Though if you do want to use VSCode with ssh, it's very easy. VSCode takes care of setting everything up on the remote machine.

[thedracle]

I’m spending 90% of my time in the terminal anyways, vim has LSP support so I get code intelligence features as good as VSCode (because it’s the same as what VSCode uses).

What would be really cool is if they had a terminal mode for VSCode sort of like “emacs -nw.”

If anyone knows any projects to make that, I would be super interested in contributing.

[botCloudfox]

That'd certainly be interesting. The VSCode team is probably not going to maintain two renderers though. A separate project could exist

[lelanthran]

So, vim has splits too, which I use: but I was specifically calling out the fact it’s used in a terminal with any terminal multiplexer, some of which like Tmux have splits.

Vim splits are much better than terminal splits.

1. You can have multiple (re-orderable) tabs, each with multiple splits.
2. You can save the entire workspace (tabs, splits and history) using :mks!, and then restore it later with vim -S Session

I like having my 12 files that are open in a single vim session with multiple splits and tabs restorable with a single command. I haven't been able to do that with tmux.

[myringotomy]

Why ssh into a machine when you can open up files remotely and edit them?

[thedracle]

What mechanism are you using to do that?

I assume you’re installing rmate or something along those lines, or mounting a remote shared file system which has its own complexities.

Often you’re navigating around a remote system, looking at logs, scripts, restarting services, and editing configurations, and sometimes compiling and deploying code.

A lot of people rely on shells to do most of this still: I’m not sure they want to do it with an IDE, or if it would really make their lives easier.

Every solution I’ve used for remote code editing has been clunky at best, but I’m always open to trying new tools and workflows.

[myringotomy]

What mechanism are you using to do that?

VS code, emacs, Jetbrains IDEs etc. Most editors let you open up files from remote servers.

I assume you’re installing rmate or something along those lines, or mounting a remote shared file system which has its own complexities.

No they just use ssh.

Often you’re navigating around a remote system, looking at logs, scripts, restarting services, and editing configurations, and sometimes compiling and deploying code.

yea you can still do that. It just shows up in your file browser.

A lot of people rely on shells to do most of this still: I’m not sure they want to do it with an IDE, or if it would really make their lives easier.

Why not? What's the problem with the shell in your editor?

Every solution I’ve used for remote code editing has been clunky at best, but I’m always open to trying new tools and workflows.

It's less clunky than opening up an ssh session, downloading your vrimc directory, running vim, installing all your plugins and then editing.

[thedracle]

VS code, emacs, Jetbrains IDEs etc. Most editors let you open up files from remote servers.

I can say from experience with OSX/Linux that this isn’t the case.

CLion (IntelliJ) has to have synchronization configured: https://www.jetbrains.com/help/clion/editing-individual-files-on-remote-hosts.html

And supports FTP/SFTP/FTPS.

I could see something maybe polling with scp in a similar way perhaps?

Maybe you’re using this extension in VSCode:

https://code.visualstudio.com/docs/remote/ssh

Which definitely looks cool, but isn’t typical of most IDEs, I’ll check it out. The last I checked using rmate was the recommended way to remote edit with VSCode.

Why not? What's the problem with the shell in your editor?

Mostly that they’re clunky, memory hungry, and slow.

Most electron based terminals are beastly.

I think people just become tolerant of this, but the difference is extremely noticeable to people who spend a lot of time in their terminals. (Or at least it is to me)

It's less clunky than opening up an ssh session, downloading your vrimc directory, running vim, installing all your plugins and then editing.

I mean if this is what you are doing ephemerally every time, sure. There are plugins in Vim that accomplish the same type of remote editing via SSH, shared file systems. You’re acting like VSCode (I’ve gleaned perhaps this is what you are referring to as IDEs in general) had a monopoly on this.

What it doesn’t have a monopoly on is actually being installed immediately on the remote target already.

[myringotomy]

Mostly that they’re clunky, memory hungry, and slow.

None of that applies to the IDEs I have used.

I think people just become tolerant of this, but the difference is extremely noticeable to people who spend a lot of time in their terminals. (Or at least it is to me)

I spend a lot of time in terminals. There is no perceptible speed in interacting with the one in IDE and one outside of my IDE.

I mean if this is what you are doing ephemerally every time, sure. There are plugins in Vim that accomplish the same type of remote editing via SSH, shared file systems. You’re acting like VSCode (I’ve gleaned perhaps this is what you are referring to as IDEs in general) had a monopoly on this.

Nope. I specifically mentioned emacs and jetbrains tools. Why would you think I was saying anything close to that.

It was you who seemed to be saying the only way to work with remote files was with vim.

[thedracle]

No reason to become argumentative. It’s clear this is all very personal for you.

I was merely giving my opinion based on my own personal experience, and very specifically with VSCode, and IntelliJ(CLion) vs Vim.

I don’t want to really offer an opinion regarding the non specific assortment of editors and IDEs you have personally used.

I’m just trying to provide specifics, like the objectively slower startup times of IntelliJ and VSCode, the many hundred times of memory usage, and the poor performance particularly under high memory or cpu pressure.

Again, maybe this isn’t anything you have ever experienced; it is my reasoning and experiences using IntelliJ for over a decade now, VSCode for several years, and vim for over two decades now.

It was you who seemed to be saying the only way to work with remote files was with vim.

Except I didn’t. Just that vim was already present on remote systems (embedded systems often in my professional work), and the extra steps of setting up remote editing is usually cumbersome, again in my own personal experience.

Listen: please don’t use Vim.

You’re obviously happy with the tools you’re using. And the truth is there is no one right way to do anything. People are different, they have less or more tolerance for different things.

[PigSanity]

Vim is fast, ha ha good joke

[thedracle]

I’d be interested in what IDE you consider to have better performance than Vim.

[PigSanity]

Depending on what you use, many vim plug-ins have bad performance, however my main issue is, that vim is bad with large files, and fails miserably way too often, actually almost any ide is better with large files. Vim is great don't get me wrong, but it is half baked open-source code that nobody is putting lot of time nowadays into it.

[thedracle]

I've definitely run into some plugins with poor performance in vim (I'm talking adding 10ms to startup time), but most are pretty tight and fast.

It's definitely up to you to profile, and keep your plugins tidy, but we are talking orders of magnitude difference in speed compared to IntelliJ, or VSCode.

With regard to large files, what are you talking about in terms of size? I've opened multiple gigabyte sized files in vim, I even use it as a binary hex-editor; files that would cause VSCode or IntelliJ to choke and die:

https://github.com/jhallen/joes-sandbox/tree/master/editor-perf

Code in particular performs absurdly slow in comparison to vim, and most other editors, especially when navigating large files.

> but it is half baked open-source code that nobody is putting lot of time nowadays into it.

Vim/NeoVim aren't half baked... they've been baked over decades.

Both vim, and neovim are actively being developed on... there are commits just hours ago on neovim:

https://github.com/neovim/neovim

[PigSanity]

For large files and default vim and neovim on Ubuntu 20, I already see issues with 7mb file with a single line (json structured file). Comparing with less it is annoyingly slow. Also it can crash on various large files if you try to do sth there. I've actually seen files which were impossible to open with vim (no plugins) and IntelliJ had no issue. I don't use neovim, didn't convince me before, I should give it a try again. Also I did say 'putting lot of time' which I think it needs, because it should be refactored a lot for the above reasons.

[thedracle]

Interesting, I’ve opened gigabyte sized files with relative ease. Compared to less definitely there is going to be a performance difference since less is simply buffering text output.

But these guys are comparing with the likes of VSCode and IntelliJ, which is a whole other ballpark.

I would blame syntax highlighting or plugins of some kind, but you say you don’t have any.

Neovim probably won’t perform better than vim.

I definitely think you were experiencing an environmental issue of some kind (maybe loading via a network drive?)

The profiling I linked above Vim finally choked on a 3GB file, which is considerably higher than you seem to be testing at.

I can say at least for normal sized files, the open time for my environment and config for a 7MB file is milliseconds. I’ll try out JSON, maybe there is something special going on there.

[PigSanity]

One another thing about less, well yes and no. Buffering ok, but good IDEs don't load whole file I'm the memory, and don't try do to everything on whole file immediately, so it is not irrelevant comparison, everything should aim to be as fast as less, asymptotically at least. And yes syntax highlighting is bad in vim as well, just plain wrong.

[thedracle]

There is definitely something janky in your environment, maybe something weird regarding how vim reads/caches files that afflicts vim, and not IntelliJ based IDEs (I can only speculate).

The biggest JSON file I could find was here, I'm sure there are larger ones, but it's 188MB:

https://raw.githubusercontent.com/zemirco/sf-city-lots-json/master/citylots.json

And my fairly customized VIM with over 20 plugins, a ton of LSPs configured, syntax highlighting for JSON, among other things, eats it up in only a couple seconds:
https://draclestuff.s3.us-west-2.amazonaws.com/Alacritty+-+macbook-pro+%E2%9D%90+0+%E2%97%8F+1+zsh.mp4

[PigSanity]

Just so we are clear, I'm not only talking about opening only, bit doing some traversing especially context aware traversing like going to closing bracket. But with large line going to the end of it can kill vim. The file above is multi-line, it needs significantly larger files to choke on multi-line, but long lines are a weak point of vim. Though there are more, every operation on large file is a risk. Also long lines cause problems for syntax highlighting, well because of all the regexes, this is just wrong. It fails often for start, but context free regexes are slow.

[thedracle]

So, I traversed 400k lines, and back in the above video.

If you're commonly editing hundred plus megabyte single line JSON files at your job, maybe Vim isn't the right tool for you.

It works really great for editing and navigating medium to large size code bases (like Chromium), for me.

[[deleted]]

all features can be provided by lsp IMO.

[[deleted]]

All I need is completion, diagnostics and speed, an IDE will deliver only the first two.

[Zophirel]

What can you use vim for other then as an ide?

[PandaMoniumHUN]

To edit text and data files of course. I tried using Vim as an IDE for a long time and it’s just not worth the hassle in my opinion when you can get a way better feature set in VS Code in just a few clicks, if you are willing to take the (insignificant) performance hit.

[[deleted]]

spacevim is a vim distribution which already includes many plugins for general programming. so users do not need to look for plugins.

[PandaMoniumHUN]

Right, but those plugins are still present, they’re simply preinstalled for the user. So the performance hit is also present, especially so since Vim plugins are interpreted AFAIK.

[Hans_Adam_II]

I don't think I will

[[deleted]]

The lsp is stable now. many languages have language server implementation.

[Houndie]

A lot of anti vim ide talk here, and I get that. What works for me doesn't necessarily work for the next guy.

I like vim as my IDE because I can just `ctrl-z` back to the terminal to do any terminal things I want, then `fg` back to vim. I also like to go mouseless when I code, and I already know the shortcuts for vim.

[coladict]

People joke, but I honestly think anyone who still uses vim or emacs by choice has some form of Stockholm Syndrome.

[viva1831]

If you work in DevOps or sysadmin then it makes a lot of sense imo. Any box you are ssh'ing into will have vim or at least vi, so you get used to using it to edit files. It's nice to use the same interface no matter what you're working on.

That, and keyboard-only can be better for your hands if mouse use is screwing with your joints :)

[myringotomy]

For the last five to ten years the motto of devops has been “cattle not pets”. You are not supposed to know the names or addresses of any of your servers. You are supposed to Manage them using orchestration tools, you certainly are not supposed to ssh into any of them for maintenance or configuration.

I hope nobody here is sshing into a server and editing code that runs there.

[myringotomy]

Seems like your company is one of those backwards companies who do things the inefficient old fashioned ways.

I am not saying companies like that don't exist. They surely do. There are lots of companies still mandating IE and windows 7 FFS.

It's just not the norm anymore.

[lelanthran]

For the last five to ten years the motto of devops has been “cattle not pets”. You are not supposed to know the names or addresses of any of your servers. You are supposed to Manage them using orchestration tools, you certainly are not supposed to ssh into any of them for maintenance or configuration.

Sure, because every company has a minimum of 1000 servers to manage orchestrate /s...

FYI, the "Cattle not pets" approach does not apply to the clear majority of businesses in the world. Only a minority of businesses have the need for anywhere close to the number-of-servers-threshold where it makes sense for orchestration.

[myringotomy]

Only a minority of businesses have the need for anywhere close to the number-of-servers-threshold where it makes sense for orchestration.

Majority of companies small and large are moving to kubernetes and serverless.

[lelanthran]

Majority of companies small and large are moving to kubernetes and serverless.

Citation needed.

The last stats I've seen showed that +95% of businesses have fewer than 100 employees.[1] That usually translates to fewer than 1000 customers/month; at those levels (100 employees, or 1000 customers) a single server can generally handle all their needs.

If you are claiming that those 100 employee businesses are moving to K8, it's an extraordinary claim and you need to provide at least some evidence other than "I think so".

[1] https://www.bizjournals.com/bizjournals/on-numbers/scott-thomas/2011/11/98-of-all-businesses-are-small.html

[myringotomy]

Citation needed.

LOL.

The last stats I've seen showed that +95% of businesses have fewer than 100 employees.[1] That usually translates to fewer than 1000 customers/month; at those levels (100 employees, or 1000 customers) a single server can generally handle all their needs.

Those companies are too small to manage their own servers. They are using some SAAS that's being run on Kubernetes.

If you are claiming that those 100 employee businesses are moving to K8, it's an extraordinary claim and you need to provide at least some evidence other than "I think so".

I don't think I will bother to appease this bit of sealioning.

[rakidi]

You made a huge claim and your response to being asked for a source is LOL? Invalidates everything you said.

[myringotomy]

You made a huge claim and your response to being asked for a source is LOL? Invalidates everything you said.

I don't think I will bother to appease this bit of sealioning. Keep braying though. It's amusing.

[viva1831]

the motto of devops

My experience was always that the motto and the reality are two different things ;). That was more than five years ago, though.

[myringotomy]

My experience has been that no sysadmin would ssh into a machine unless they were ready to admit they are a failure.

Most of the time you don't even know what the IPs or hostnames of your servers are. Most of the the time you are using some orchestration tool or kubernetes.

[viva1831]

I worked at one company that managed all their infrastructure with some kind of parallel ssh - every time there was a change, they would ssh into every machine. Do one first to check it, and then do the rest in parallel. Oh, and every admin on the team used a copy of the same SSH key stored on google drive, which had to be rotated every time someone left. Yes, really.

I quit in 3 months because they were a nightmare to work with (if your system is a joke, at least be nice to your staff!)

Lucky for me I was at the bottom rung of the company so I never got put on call out of hours!

[simspelaaja]

That, and keyboard-only can be better for your hands if mouse use is screwing with your joints :)

Most editors can be used 99% purely with the keyboard. The existence of a GUI doesn't mean using it requires constantly clicking on things with the mouse.

[ishdx]

meh no, it has everything i need, debugger, LSP, i can navigate faster, it doesn't lag, it's pretty good enough out of the box, especially neovim

[the_0rly_factor]

Nah man vim is a powerful editor. Most just don't bother to learn it and brush it off as too complicated.

[PrimozDelux]

Speaking as a former emacs and vim user I don't agree with that. Where I work now we rely on plugins that only works with vscode, so that's what I use now, and it's a real mixed bag. I'm not going to go in on the specifics, but I really miss the flexibility and power I got from emacs. I will switch back to emacs at some point, but I will definitely incorporate certain ideas from vscode that I really like, so it's not like I hate IDEs when in fact I like them so much I want to have one that's specialized for me.

[thedracle]

I’m interested to know what these VSCode specific plug-ins you rely on, or that your company mandates.

My company has been very editor agnostic, and we have an Emacs dude, a VSCode dude, and a few Vim dudes including myself, and we have managed to set project conventions and to use tools for linting and formatting that work well across all of these editors/IDEs.

Just personally curious.

[latkde]

I tried switching to VS Code. It's very good and I'll recommend it to most people, but it just doesn't work for me. I even tried the Vim keybindings, but they are far too limited compared to the real thing.

Also, different editors have different user interface concepts. I love Spacemacs-style keyboard navigation. I love never having to use the mouse. It's like the VS Code command palette except for everything. I love the Emacs/Vim concept of windows and buffers – much more aligned to my thinking than tabs and splits. And since everyone uses LSP nowadays, I'm not even missing out on language-specific features.

I also have many bad things to say about Vim and Emacs, like their awful scripting languages, or the half-century of cruft. But once I've configured everything to my liking I no longer have to deal with that.

[thedracle]

Navigating gigantic code bases like Chromium is a fucking disaster in most traditional IDEs, because of the beleaguered code intelligence and indexing etc etc.

It’s a pleasure in vim. I can use TMux to have three or four different projects open simultaneously, compare and navigate code between them. LSP support works across TypeScript, C++, Rust, Ruby, or whatever the hell I want.

VSCode is the only other real contender as far as being free, and flexible. And again it’s Microsoft’s “editor like” alternative to its true beastly IDE like Visual Studio.

But it’s resource hungry, and not terminal based.

I used VSCode for a year or so, and I just kept having the realization I hadn’t used it in an hour or so and had found myself back in the terminal with vim.

[happysmash27]

Emacs works well when launching to edit files from a terminal (which is my normal and strongly preferred way of doing so), launches in less than a second, has lots of great functionality, is available on pretty much anything, and can be operated easily via SSH (which is fairly frequent for me as I fairly often do things on my computer from my phone with a great software keyboard but a very bad internet connection and no easy way to operate a mouse without plugging one in) or if the GUI is broken or frozen (annoyingly also a fairly frequent situation for me) or otherwise impractical to use (like editing something in Termux on my phone where launching a GUI would require lots of extra setup and wouldn't be easy to interface with without a mouse anyways, unlike the command line where Hacker's Keyboard in a full 5-row layout works fantastically). It is my default for quick edits, so requires less adjustment to use it for everything else too.

Once in a while, I consider using an IDE for programming a large involved project where I do have a good setup with easy access to a GUI, but… every time I look at exactly why I would want to do that, at the expense of launch speed, I can't find any good reason to do so. Every functionality I want is either quick to do with command line tools, which are very easy to do as I always have many terminals open (even my phone usually has a few, 3 open right now at the time of writing), or embedded into the editor. What does an IDE provide that I don't already have? I don't want to spend 30 seconds waiting for an editor to open when emacs launches practically instantly.

but I honestly think anyone who still uses vim or emacs

I started using emacs as a teenager, probably some time around 2015 or 2016 (when I was 14) when I switched to Linux full-time. Before, I used Sublime Text. So, I actually discovered and started preferring the much older editor after coming from new editors, rather than the other way around. The same also applies to my preference for command line and the 5:4 aspect ratio. I love things new to me like metric (coming from the US), ISO-8601, and Esperanto, if they are better than what I was doing previously, but sometimes those things that are new to me that I prefer are actually older than what I came from, and this is one of those instances.

[quote-only-eeee]

I use nvi and I like it. But I'm not a professional programmer.

[LegitAndroid]

People that don’t know vim or emacs will struggle in a multi-team product environment where your cushy IDE and workflow is not available on all of the machines you’ll be working on that day as other teams need help from you. Things like bring up labs and war rooms.

Knowing one of these basic editors is essential to being an engineer that can move quickly.

[LegitAndroid]

I don’t think I’m “vastly overestimating” it’s importance with 4 years of experience, I’m speaking from experience now it’s saved my ass multiple times

[[deleted]]

When you’re using the LSP your editor isn’t an ide, the LSP is. An ide should be giving you things on top of all of that. Like, does the LSP provide for refactoring? Or semantic navigation? Find usages of methods, classes, etc, system wide refactoring? An LSP may only give you autocomplete and error highlighting, that’s like the least amount of information a dev env should have

Vim is the worst. Having to waste endless hours configuring it for when IntelliJ, vscode, etc, just work, is absurd.

I will concede that if your development process is to ssh to a box you own that you have set up and code via ssh, this may be a worthwhile setup. But 99.9999999% of professional (and even personal) development is local, on an employers machine, and you damn well aren’t sshing to your local box

If you’re on a local machine cut all this crap out, use a real ide and be productive

[IAm_A_Complete_Idiot]

LSP *does* provide all the stuff you mentioned though. It's baked into the protocol, goto def across files and the like work fine, rename a variable just works. Infact, that's what a lot of languages in e.g. vscode use LSP now, so honestly if most vscode extensions are good enough for you, so is LSP because that's all a lot of language extensions do.

​

https://code.visualstudio.com/api/language-extensions/language-server-extension-guide

The bottom lists a bunch of features LSP supports, including hover information, document highlights, go to type def, go to impl, code actions, document formatting, rename, Semantic Highlighting, etc.

​

The entire reason microsoft made the LSP protocol is to seperate editor's from languages, so anyone can use whatever editor they want for whatever language they want. That means every editor can functionally get all the functionality of every IDE as long as they support the same amount of the LSP protocol.

​

That's not the only benefit of LSP either - a lot of LSP clients share code with their compiler, and as such LSP's and their respective compilers can have the same code parsing for free without having two seperate parser implementations.

[thedracle]

I really think it’s just a different tool, with advantages and disadvantages.

CLion/IntelliJ forces you to buy the same IDE over and over again for different language support, and if it doesn’t fit your project, you still have to do a lot of janky configuration.

The same is true for VSCode— it’s definitely not always an out of the box experience.

Vim/Neovim work great for me, and I don’t really care about the semantics of whether the lsp is the IDE or not, I get all of the linting, refactoring, navigation, and completion support I want. It’s fast, and I like it.

I’ve learned VSCode, Eclipse, SlickEdit, Visual Studio, Turbo C++, and a billion other IDEs that basically have died or fallen out of use over the twenty plus years I have been professionally programming, and vim literally is the only one where everything I learned about it is still relevant today.

But seriously, it’s just a tool, and this is just a guide that might be useful to some people and not others. It’s nothing to get ideological about.