To be blunt, I think this is not good. The claims are dubious on a factual level (you really can get most IDE functionality in Vim, or at least in NeoVim) and it’s framed in such a discouraging, knowing way. I admit I might have found this motivating when I was younger (and that’s probably why it’s framed this way) but ultimately on net I think this is pointlessly intimidating.
Unrelated: Helix is a great vim-like editor that has a selection-first editing model that I prefer and requires much less configuration. https://helix-editor.com/
One of my favorite things about using vim as my main IDE is, I can run it on a linux server. My work has me moving around the country. I program on a vim instance running on a remote server. I just need to carry a tiny laptop around.
I usually get an okay ping(<100ms) and if its unacceptable (overseas travel) I change the vm location. Depending on what I am working on I can increase or decrease resources and since things I program usually end up running on ubuntu servers it feels right at home.
edit-
Incase anyone is wondering, I actually started doing this since one of my laptops once got lost while traveling. Airline did find mybag later, but the two weeks without it drove me crazy. Now, if I want I can just show up anywhere get a fresh laptop load up my ssh keys and im all set lol.
While I don't use VSCode myself, many students and faculty at my school did, and the VSCode SSH extension seems to have some performance issues. It works by copying a server binary onto the remote computer; however, that process is quite heavy in terms of resource usage on the remote, using hundreds of MB of RAM in usual cases (which adds up when you have hundreds of students doing their assignments on one server), and 10s of GB at the extreme. It's also particularly bad about cleaning up after itself: oftentimes, when users disconnect their session, the VSCode instance continues running on the remote server forever until it's manually killed (and every time the user starts a new session, it starts a new process instead of reusing an old one).
Our school servers have a 200-process-per-user quota to prevent accidental fork bombs; students frequently hit this limit and become unable to log into a shell, because their entire quota is taken up by VSCode SSH processes that have accumulated over months.
The combination of these two effects have caused serious problems over the past couple years as VSCode adoption has rapidly increased among the student base, to the point that some professors have banned VSCode from their classes, due to the SSH extension making the class servers completely unusable for everyone during the big rush a few hours before an assignment is due.
No sync issues, no freezes. Your code editor/tools/coding happens in a single computer.
VScode remote extensions are really good though, the best of any GUI editor. But that BLOB it installs on remotes can take a good chunk of scarce VM RAM.
This is four years old. It was outdated at the time it was written, and now it is woefully outdated.
For example:
> From sketchy terminal integration, to being single-threaded, via the lack of anything resembling a proper internal plugin API, nothing in Vim can be leveraged to give you a convincing Integrated Development Environment.
I was thinking the same thing - granted, the OP is technically referring to Vim and not NeoVim. Still, today’s terminal integration is incredibly smooth, and Lua in NeoVim has been a dream for someone who spent way too long attempting to learn VimScript and has never written a lick of Lua in my life.
I'm a big fan of Vim, but I hardly use it as my primary editor anymore (applies for Neovim as well).
I think the ecosystem is amazing, but I hardly have the patience to set things up to feature parity with other editors. Debuggers are the biggest missing/hard to configure feature.
I do, however, use Vim bindings in every editor that supports them (and extensions for browsers like Vimium).
The extensions/Editor functionality are hit-or-miss; some are missing key bindings that I use often, or features don't quite work correctly, but I find it much more enjoyable to use than the "typical" approach.
The VSCode one is pretty good (even has EasyMotion/Sneak out of the box, if that's your style), but often seems to slow down and buffer keystrokes on heavy load/undo seems very hit or miss.
For 20+ years I did all my coding, development, and miscellaneous tasks in Emacs. But I used vim exclusively for writing emails - initially with mutt, and later with different mail clients.
There were times, now and again, where I'd use vi, or vim, on solaris, or other "weird" systems. But basically I used vim for emails and emacs for everything else, and I think that was a good split.
Were I telling somebody to start a new editor these days I think I'd probably echo the recommendation to use the integrated tutorial, but after that just "jump in". gvim, emacs, and similar have menubars that help with many things before you learn the keystrokes required and there's no shame in using them. The article suggests learning and experimenting before switching, but to me that seems very counter-intuitive.
Mason brings a lot of what I needed for LSP, and their DAP servers are getting better. Debugging in (n)vim will likely remain a fun trudge for a while but it is getting better.
I found a lot of issues with trying to get a “good” setup, or got frustrated that moving from one job to another meant attempting to port my working setup to a new machine and new projects. I recently went back to NvChad and have done almost no custom config and I love it.
> Debuggers are the biggest missing/hard to configure feature.
Do you know about :termdebug and what are you missing with it? It's just dbg hooked into vim, and you can use any other compatible debugger instead if you prefer, for example rr.
That's the beauty of vim, the tools you use are the tools you'd use in your terminal anyway.
Least we forget, UNIX type systems is an IDE with many small tools. Plus you can batch up mass changes and run in background which you cannot do with an modern IDE.
I made the mistake of using vim before switching to an IDE. I bought in to all the tough guy talk and put tons of effort into learning the arcane key combinations and trying and failing to get plugins to work to make it do basic programming stuff. Utterly pointless - use an IDE - if you are a professional programmer it is the one tool you use all day every day, spend the money for the best one you can that has a team of people working on it full time, paid well to make that IDE awesome.
I use vim all the time now for simple text editing when logged in to a machine but I'd never dream of using it for programming. I know how to cut and paste lines in vim and how to save and exit, nothing more needed.
I set up F2 to run the shell command on a line in nvim, and I noticed it improved my shell productivity. I run tests with with cargo test, rspec, pytest etc by writing the command on a line, hitting F2 and all results are just there. I can navigate to errors, search traces or whatnot all the same as I navigate the code. I can search GitHub issues when I'm writing a commit message with gh. This is just a simple productivity hack that I can't replicate in other editors.
I'm sure there are better special tools but vim is the most general purpose tool you can learn and use. I never had regrets to invest time on it.
One of the counterpoint is vim not being available on Windows. But It is.
Not by default, but most critical stuff aren't there by default anyway and vim will be one of the easiest block to have ready.
Then Windows comes with WSL, where I think most people who even care in passing about vim will spend their time, so we're back to the editor they'd use on Linux anyway.
That was to me the main reason I went with Vim when I first touched an nuix system, and to this day that's still a good enough reason to keep using it where a full IDE isn't required.
Any system I've seen had a simple enough way to get vim, that hasn't changed.
At the time of writing, the supposed ubiquity of Vim, or rather Vi-clones, was often touted as a strong selling point by people with a severe case of Linux-myopia.
The "counterpoint" is not that Vim is not _available_ on Windows. It is that Vim is not on Windows _out of the box_. You must install the native binary to have it or, like you suggest, install _another system_ on your machine… that actually comes with Vim.
"Can have X" is not the same as "has X".
FWIW, experimenting with Linux is also what got me hooked to Vim (and the shell and all the rest) in the first place, but rose-tinted glasses are not for me.
I'm with you on vim not being there out of the box. I mean, even on Debian it's not in by default.
But I also feel that ship has sailed for most software. We joke that windows/macos's default browser is only there to go install Chrome/firefox or any other browser of choice, and I see the wider reality of it as most OSes requirement a decent amount of installation to get to a usable point, even for very basic tasks.
It's still easier to use software that is mostly available everywhere in mostly the same shape and form (also why so many people bet on VSCode I think)
Yes and no, if you favorite editor was Tilde you'd be in a lot more pain to have it work on most non linux.
Vim is either already installed or at one click/one command away almost whatever the system you use, that's the closest we'll ever have from "everywhere" in this day and age IMHO.
What is the consensus on productivity with Vim? I have thought about trying out the keyboard only approach, but haven't wanted to invest time in it yet. When I see people on YouTube using Vim it slightly feels like there's a whole lot of keypresses happening, but not a lot is actually gained compared to using a mouse or even frequently it seems it takes a while to do something that is much quicker with the mouse. I understand half the point is to be able to keep your hands focused in one place, but how do people feel about the productivity?
Once you start using it, you can’t edit any other way. I don’t think it’s well established whether it’s actually faster or better in any objective sense. It certainly feels faster than using a mouse, or if not faster, maybe less frustrating.
Here is how I think about it: the depth of these keyboard-based editors allows for a kind of progressive mastery and you decide how far to pursue it. Plenty of people use Vim in a very rudimentary way, barely using any of the features, and they still might prefer it. Others know certain slices of the functionality available, but everyone knows a different slice depending on how they want to edit. The point is it’s sort of an open space with lots of texture and customizability, which is sometimes how professionals like their tools. It lets you sort of build the tool into what you want it to be. And that can be true even without elaborate customization: even with a stock NeoVim install, figuring out over time which subset of features you care about is a kind of customization.
One tip I have: if you use VS Code, try the Vim extension. Or whatever IDE you use, see if it has a vim mode. That is by far the best way to learn, and it may well be the best way for you to use Vim long-term. You don’t have to change editors, you don’t have to configure anything, you can just focus on moving the cursor around in a new way.
The difference in productivity is hard to measure. What's really gained by vim bindings is not having to leave flow state to move the cursor over there and then change that word for a different one. The same operating can be done with a cursor, but in having to leave home row and then come back to it, your mind has a chance to wander and you start thinking about whatever else is going on in life. Like why you're using a mouse and not vim keybindings.
> And if I want to look around a single file, I feel like anything else besides scrolling would be quite inferior in terms of speed and accuracy.
{ and } jump you to the previous/next new line, respectively. Also page up and down work of course, as well as arrows or j/k. But I’m rarely scrolling in vim because I know what I’m looking for and how to get there faster.
> And moving around lines and words is already quite optimal enough without a mouse, using arrows and option/command modifier.
Fair, and in vim you have a single key to jump words (w/W) or the f/F commands (along with ;) to quickly jump through a single character in a line. Example:
This is a string and I want to get to the last letter.
If your cursor is at the beginning of the line, you can just type “fr” and then hit ; until you’re at the “r” in “letter”. Or hit $ since really you just want to get to the end of the line. Or “f.” since there’s only one period. Or…
> And also I use a lot of ctrl + f to move around, which I find quite reliable.
And in Vim you can use / to search ahead, or ? to search behind. And n/N to jump to the next/previous match. Maybe your cursor is on the word you want to find more of in the file? Just hit * to jump to the next instance of it and n/N to jump next/previous.
Let’s say you want to change some text enclosed in parentheses (a very common operation in programming). How do you do that in your IDE? In Vim it’s just ci( .
Very simply, for me, keeping my hands on the keyboard feels right and means less movement overall. If I’m typing and want to correct something two words back, say “how rae you?” I can either
- grab my mouse and click where I want the cursor, fix the typo, and then click back to where I was (or hit End, or was it Ctrl+Right? Opt+End?)
- type <Esc>Faa<Delete><Delete>ar<Esc>$
Ok, that’s a lot of weird keystrokes, but in my brain my hands just did “jump back to the a in ‘rae’, delete the ‘ra’, type ‘ar’, jump to the end of the line”.
Over a decade of Vim later and these motions are second nature to me, and using my mouse is usually reserved for the times I’m not in Vim. I can’t say I’m faster or more efficient, but I know how to get my cursor to exactly where I want it and how to manipulate, move, copy, delete, etc, in a way that feels natural and intuitive.
And every other tool that supports it. I use it everywhere, window manager, terminal and every terminal program I use (via readline), my browser, and the list goes on. I rarely have to reach for my mouse, if I do it's frustrating and breaks my flow and I will fix it next time I have a few minutes to spare. I even have a shell script to move the cursor out of the way.
Now you're just grasping for straws. By adding one line in ~/.inputrc i have vim magic in just about every TUI program available (in theory some may not, but I've yet to encounter it). Don't make it sound more difficult than it is just to make a point.
Lots of tools for power-users come with vim keys today, and when I choose a tool it's one of the first things I look for.
You are saying that a more complicated setup and harder to learn tool is superior. Not sure i get your point. Parent has a point with the number of keystrokes.
I never described it as superior, I'm just pointing out GPs exaggerations. I would never expect my grandmother to use vim keys. But she's not the HN demographic and vim doesn't have to be complicated.
Github already has vim inspired keys (/ to search, gX to navigate and so on), I don't use Confluence or Jira but a quick search shows me they also have some (/ to search, gX to navigate, n/p for next/previous) without changing any settings. All your examples has vim keys without me doing anything at all.
In my browsers I use vimium, and you can embed actual neovim into textboxes with a few different addons, one of them firenvim. I rarely use GUI though and that's my point, I don't have to since 95% of my work is in the terminal.
In my experience non-vim people are neither more or less productive than vim people. Pick your poison. Productivity comes down to so much more than typing/navigating/yanking fast. Especially when it comes to programming, which is 95% thinking, 4% swearing internally and 1% typing.
There is no objective evidence that Vim makes you a more productive programmer. There is no evidence that avoiding a mouse makes you a more productive programmer. Use the editor you want! Vim is faster at some things and slower at some things.
The main drawback of all the keypresses you see is that Vim is an imperative editor: You have to tell Vim how to edit text by glueing together lots of small commands.* IDEs are declarative editors, you say "rename this variable" and they do it.
* Ask your local Vim nerd to rename the file they're editing. It will be entertaining!
> Ask your local Vim nerd to rename the file they're editing. It will be entertaining!
Oh that’s easy though, friend :)
:!git mv % new-name
> IDEs are declarative editors, you say "rename this variable" and they do it.
Most NeoVim setups I’ve tried recently include LSPs with code actions, so now I just hover a variable and do “<Space>ra” and I get a little popup window asking me for a new name. I type it, hit enter, and the reference is updated in all relevant files.
I was indeed entertained with your imperative instructions to move the file, which is also slightly more annoying if your file is not at the top level!
Personally, I'm just used to the bindings and I strongly prefer the editing experience, and think about navigating text via Vim bindings as a matter of habit.
The biggest "productivity" changes for me in any IDE/Editor is the ability to fuzzy find for an arbitrary symbol, a keybinding to search for and subsequently open a file, LSP features like "goto definition", "find all references" (and jump back to where I was quickly) etc.
I think maybe you shouldn't focus on the "productivity" - that's a fairly arbitrary metric, and difficult to measure - it often has more to do with how many bugs you have, how organized you are, and what you are trying to accomplish, how good friends you are with your boss/customer, and very little to do with which editor or what keybindings (or which language, even).
Instead, it is better to think about communication protocols - for a second consider something like the internet - something like handwaves, gestures, while theoretically analog and hence containing infinitely more data, they are very difficult to transcribe, send to the other side of the planet, and interpret.
I'm not saying these things cannot be done, but I imagine the internet would not exist if we had resorted to using thumbs up/down as our method of transferring information between "computers". We used a more appropriate, binary-based, protocol, and now we can send characters and have discussions! Maybe even include a couple hand-wave emojis!
Editors like vim/emacs are similar, they "feel" more productive because they are in some sense, "closer" to the code than a mouse can be. If I mainly am using a mouse (nothing else), then I probably should not be writing code at all and instead should be recording my program with hand waves, or something.
I'm not saying IDE's aren't useful, but that's because programming is neither about those mad FPS skills (mouse) or nor mad text editing skills, they are built to manipulate and mangle symbols, which is what we actually use (for better or worse) to program computers.
That's one reason why I find IDEs (often coupled with an emacs keybinding) mad "productive" - I can mash shortcuts all day long and most of my code writes itself (I'm not even using AI). I'm much closer to communicating with my code/debugger than having to mouse click around. Some of the transforms/translations are sometimes odd, or the UI environment is restrictive, so I'm using the mouse then for those situations. I often, frequently, find myself "out-coding" my peers.
But a good IDE is mostly aimed at being really good at modifying/generating symbols (in the context of a project). Its not very good at text formatting (usually handled by some plugin), for instance. And where it really falls apart, there's no control, i.e. usually it is a complicated product, with lots of pitfalls, speedbumps, "I screwed up and jacked my cache please restart me". And that nixes a lot of the "productivity" gained.
So that remains where a tool like vim/emacs/notepad++ etc shines, when you need to communicate with (roughly structured) text, they won't crash on you, they won't "get in your way", they won't need you to define an AST syntax in order to understand your little mini-language, and, at least of the extensible ones, you can define whatever it is you need or want to. IDEs are usually really, really bad at that sort of thing, if you find yourself needing to do that, you'll often 1) learn to cobble something together in a script 2) learn to cobble together something approaching that in an extensible editor 3) writing a language 4) writing a plugin to write your language in your IDE, to solve whatever it was....
Ironically text editing is the thing I like least about vim. I would switch to an IDE if it provided the level of programmability Vim has. For example, I have a binding which, when used on a netlink command, opens the corresponding implementation in the kernel. How do you do that in something like VSCode? I guess I could write an extension, but in Vim it takes like 2 lines of code that you write once and forget about it.
Or another example - you can analyze log files in terminal buffer by folding based on patterns, multi-color highlighting, etc.
The ability to quickly and easily(-ish) script vim is incredibly useful. At one point, because of environment constraints, the easiest way to run unit tests was either to run them all or to specify the file I wanted to test. A little bit of googling and playing around and I had Vim read my current spec name, chop it up to find the correct source file name, spawn a terminal and run the test command using that source name anytime I wrote a change.
Thankfully I’m somewhere with sane tooling that watches for changes and only runs relevant tests, but back then this little foray into “how do I make Vim do a thing” saved me a ton of time.
Counterpoint (or at least counter-consideration): Sometimes Vim is really, truly, absolutely the very best tool for the job and very much worth your time.
I learned Vim because I had to edit code through an ssh tunnel, limited to text only, and nano just wasn't cutting it any more. This is pretty much the exact thing vim was born to do, so it was a pretty clear win to learn Vim, despite the horrifying learning curve. And now I know Vim!
Well there are a lot of text-only editors better than nano. Emacs of course is the big one, but there are probably a half-dozen others with varying amounts of featuers. Unless you also meant "installed by default" then vi[m] is probably about it.
I moved to NeoVim recently and I never missed VSCode. Most of my development happens in remote machine and I found VSCode symbol look up, code navigation painfully slow and sometimes it doesn't autocomplete. When I update my repo, all linting and LSP features stop working in VSCode. In NeoVim, it happened 0 times so far. So, yeah, OP is wrong. VIM(NeoVIM may be) is as good as any other IDE out there.
One could say the same about any interest, really...imagine bragging what sort of car you drive, as if that makes any real difference.
Of course, you say, driving some expensive car means you get more attention, right? Well, yes, and it doesn't make you any better of a person...if your text editor is your car and people care about what car you drive, then maybe it also gets you some attention...
But yes it is sad that we get wrapped up in the unimportant things in life. Good to have some escapes, too, though.
My point was more that sometimes with modern internet it's quite easy to end up in a very specific and small bubble and think it represents the world.
But sure I guess you're right, as long as there is an audience willing to listen you can brag about anything. I can count on one hand people in my real life circle who would care about me using emacs.
Cars are different, they are related to economical accomplishment, which is more universally accepted as something to brag about.
You're right. But I was talking about videos like "turn vim into VS code with this one simple trick!!!" - I don't like those.
And I think the people who watch these would be better off using a regular IDE. The only reason someone would watch that is so they can haphazardly configure vim to mimic their existing workflow. I don't know. Maybe I'm being too judgemental.
> sed, awk, cut, a quick bash one-liner, a simpler editor, an infinitely more powerful IDE, an actual IRC or mail client, an actual presentation program, some online CSV-to-JSON converter, etc.
All of these will take time to learn or find. I know basic sed syntax but I'm never 100% sure that my edit does exactly what I want, so I end up running without -i and then with. I don't know awk at all. I use cut but always mess up the field numbers, and if there's multiple spaces involved then forget it. In all of these cases, it's faster for me to open the file in vim, make the change or grab the word I need, then exit. I'm not saying the tools are useless, but vim is flexible and covers a lot of use cases.
Half these examples are gui programs. Who is realistically trying to replace a presentation program with vim? These seem like strawmen to pad out the list.
Is vim the right tool for every job? No, definitely not. But I think it does well enough that it's okay to lean on it if you already know it.
Vim’s :terminal is better than win10 terminal. And than Konsole too, for that matter. (Maybe I mistaken “integration” for something else.)
to being single-threaded
Is this a problem? All language servers run async in different processes. I don’t think vscode is multi-threaded either. Multi-processed sure. Threads are mostly dead.
I’m not a vim missionary, don’t use it, don’t learn it, don’t scratch where it doesn’t itch. But these arguments make little sense. The rest varies from okay to low quality bait, tbh.
Using vim to improve typing speed is an age old misconception, bordering on straw-man. The real appeal is the flexibility to script and customize a general purpose editor and make it bend to your will.
For example, make a key binding that moves between only functions that have a particular signature. Or a shortcut that takes heap snapshots, filters and format the output to your liking, and have it displayed alongside the source file with the suspected memory leak your hunting.
Otherwise no I still can’t get used to using j and k to move up and down even after a decade of vim.
The real reason to learn vim is so you can login to any linux server and edit.
You learn it and if you enjoy it you can go deeper. I use VSCode on my desktop and I’m not about to give up a graphical IDE, but it’s great to be able to ssh into any linux server or container and be able to efficiently edit with just a keyboard when you need to.
I had to start using vim back in the early 2000s, because nano didn't make it easy to search, modify and navigate large config files using regex. It was out of pure necessity.
This is so true. Over 10 years ago I began craving the idea that is vim - and now I am a vim/neovim user, but it was a gradual process. I've used all kinds of stuff, 20 years ago TextMate was the first I used for serious programming, then Sublime Text as I switched to BSD and Linux, then Atom.
I tended to par Atom down to the essentials, but just like everyone else got gradually more and more frustrated with the performance and instability, so I began to play with vim and quickly discovered it's not so easy to jump in. I didn't want an IDE, but I did want some modern features like git integration, so my initial vim plugin count was reasonable. What I really struggled with initially was the lack of standard cursor movement, with select/deselect (autoreturn to insert), i.e what basically everything other input field and editor behaves like - even once I was comfortable with the vim way, switching between browser input fields and vim just felt annoying - eventually I configured my way around that so I can have the best of both.
Going full vim took some back and forth. Using it on servers out of necessity really helped. One day, when an Atom update broke my configuration yet again, I deleted it and went all in on vim, I'm not sure how long it's been now, probably 6 years - and I'm still learning.
So yeah... one does not simply recommend vim, but it is awesome, and weird.
My favourite thing about vim... I've had the same config from the start, it has never broken due to an update. I value that so much.
> While some recent advancements may hint at future changes in that direction, Vim currently lacks everything it would need to be considered/used as an IDE.
I disagree. Neovim can be considered an IDE with the caveat that you have to configure it as such and use plugins.
> From sketchy terminal integration
What's so sketchy about it? The terminal integration in both Vim and Neovim are decent, and you can always do Ctrl+z to go back to your "proper" terminal and do whatever.
> to being single-threaded
Sure, everything isn't multithreaded although you can write asynchronous configurations and plugins.
Regardless, Neovim is more than fast enough (and certainly much faster than the comparable IDEs) so I don't see the critique being valid.
> via the lack of anything resembling a proper internal plugin API
Neovim has a very good API for writing plugins in Lua.
> nothing in Vim can be leveraged to give you a convincing Integrated Development Environment.
Unrelated: Helix is a great vim-like editor that has a selection-first editing model that I prefer and requires much less configuration. https://helix-editor.com/