Disclaimer: I am playing devil’s advocate. I do believe Vim makes me more efficient with some trade-off, YMMV.
We, as developers, spend a lot of our time on our text editor of choice. Choosing to use Vim, in my opinion, ultimately won't make a huge difference with any other editor. The majority of modern editors are more than capable to handle the task at hand and are much easier to get started with.
You want to use Vim? Sure. After you are vaguely familiar with it, you will dive deep into Vim's ecosystem and soon learn about the variety of flavors Vim comes in and the many ways to manage plugins and configuration. Suddenly need to code in Java? well darn, you'll need to expand your code completion, syntax highlighting, and add additional functions like compilation.
And after going through all of that, would you argue that you emerged out of it a stronger better developer? Or would you say it was all but a distraction and the time spent there could've been spent on coding and learning about other facets of programming?
I use Vim daily and I love it, but it's kind of difficult for me to recommend it because it truly is a time-sink. What the folks rave about is more about Vim-navigation and not Vim itself, and that is easily solved with Vim-mode, which is available in most editors.
So, what's your stance on the general push for vim?
Top comments (88)
Personally, I love Vim for the same reason that some people love raising a banzai tree, or building a toothpick castle. If I've got the time, I like to fiddle.
Sometimes, yes, I just want to knock some code out, or navigate around a big project to get a bird's eye view of everything. At that point, I reach for VS Code.
But, if I've got the time, or what I'm working on isn't super important, I like taking the time to tweak my
.vimrcto get things just right. And then, in a couple of days or weeks, I do the next bunch of tweaking. It's fun and it's interesting.It's relaxing to me to do something small and pointless, but to do it very carefully and to do it right. I don't know. Maybe it's a "when you focus on something small, all of the big stuff fades out for a while" thing.
I think that's the reason I'd recommend Vim to somebody. Not because it's "better than your current editor", not because you'll inherently "be more productive", but because you're interested in learning something new, adding another tool to your toolbelt, and fiddling. And I think that's enough reason to pick it up!
THIS. This so hard. I have NEVER been able to put it into words but oh man, this.
I feel the exact same way. The guy nailed it.
I think it's the same as dvorak and qwerty keyboards. One can type faster on dvorak, but there is a lot of time invested in learning and practicing. If one have time to invest in Vim, I don't see any reason why not.
I personally think that there is to much programming subjects to learn, that investing much time in text editor is pointless.
Emacs does also work well for this purpose.
Totally agree. It's like knitting or oragami, but you end up with a cooler workflow each time, instead of a bunch of knick knacks laying around the house.
When the discussion comes to the point where it is "would you recommend Vim or not" I think of an analogy that I like to use: it's like recommending a bike over a car.
It might be an overly simplified analogy, and it goes together with the fact that I love my bike as much as I love vim, but it goes like this:
Vim is my bike, a car is an IDE, and your text/code is your distance. Short distance might be a script, a long distance might be a project.
With the bike you can get around. You choose short distances when you are starting, and you fall. A LOT. The better you get, the longer you ride. If you loved it, you'll love it more. If you didn't, then riding isn't your thing. You start tweaking your bike: did you choose a road bike over a mountain bike for your daily commute? that's fine, but ride. After you ride your custom bike, you don't want to use the same bike you used at the beginning. Your bike is yours and only yours. Then, you start using it for more than commuting. You ride it for fun, you do day trips, or even week trips. You use it in distances other rather go by car, but it doesn't matter, you enjoy it. And sure, you brag about it.
The car is something different. It's heavy duty. It comes with all the goodies you might need for long distances. You need to learn how to drive, sure. There are a couple of controls, you can go fast or slow, but as long as you don't get crazy you won't crash. You are surrounded by safety, sit back and strap on. Have a long distance to drive? it might come with a GPS, you just drive. (Sure, you can use a GPS with the bike, just as well as you can install an autocomplete plugin in Vim).
Some bikers can't wrap their head around people driving to starbucks and back. Some drivers are tired of the bikers bragging saying how biking is better than driving for "all the wrong reasons". Others, just choose the right transport for their commute. Sometimes you might want to ride, some other times you need to go across the country carrying a bunch of luggage, for which the car just works.
For me, it isn't about arriving, it is about enjoying the ride. Would I recommend vim? sure, why not? try it. Just know that, unlike when learning how to drive, you do fall from the bike.
Really well expressed!
I myself prefer nowadays PHPStorm for PHP development, but everything else is done in vim. The key point for me is how easy it is to script changes by recording macros and automating tedious refactorings. After all I already dug through 100k of ancient Perl code and could not have survived this without and editor that simply works.
What I most miss in these discussions is always the fact, that development environments are different. I would love to build all my software on one machine, locally and my bespoke editor config. But my reality is, that I have to analyze and debug my code on a couple thousand servers, where it simply is impractical to always have your config with you.
So my best tip for everyone: memorize the three most important settings (
:syntax on,:set bg=darkand:colorscheme desertare these three for me) so you are neither blinded nor disgusted when moving systems quickly. And while the perfect setup might have vim-airline and zenburn, you can at least live on a remote system without going nuts.Agreed. I believe that the title of the article is a bit misleading, as Vim can indeed make you more productive! if you choose if for the right task, and know your way around it. The more experienced you are, the broader range of tasks you can do productively.
The last part of your comment is also on point: if there are customization-elements that make your experience easier in a session on a remote/different machine then learning them will make your life easier. It can be even added to my analogy: if you get a bike while you visit someone else, what's the first thing you do? You set the settle to your height, probably change the gear, so that it feels comfortable. You can also drive without doing any of this, sure, but it will be a pain.
My stance on the general push for Vim - after having used it for years before moving back to modeless editors and although I maintain a semi-official Vim build for Windows - are the following considerations:
:versionis a mandatory command whenever I come across "a Vim".Yes, Vim is cool. A version of
viis installed on most Unix and unixoid systems - but then again, so ised. -- Vim imitates a concept that was made for systems which haven't been seen in three decades, but its preferences still make sense: everything is a mnemonic. A lot of that is purely emotional though. Impress your friends by not using a mouse, hoo! One could imagine higher aspirations. (My stance on syntax highlighting and code completion is a different topic... Vim's default colors hurt my eyes.)I have learned a lot in my time with Vim. One of the things I have learned is that modal editors kill too much of my time.
I couldn't disagree more. Vim's modal nature is insanely convenient and fast, whereas non-modal editors force you to waste time mousing around in menus or GUI elements. Most programmers spend far more time editing and navigating code vs writing it.
"In most cases, when I start my editor, I want to type stuff right away."
vim +starI've used several plugin managers and never had any issue installing the plugins I wanted.
"No Vim is like any other Vim" is like complaining that nobody else organizes their kitchen exactly like you organize yours. 99% of the time, you'll be using the vim you installed and configured.
As for the original question here: a task being difficult and time-consuming isn't a good reason to avoid it, if the payoff is good. Learning vim is one of the best decisions I've ever made.
And since every single distributor compiles different options, you can never be sure about which they are.
If you can use git and GitHub, you can compile your own vim in easily less than 5 minutes.
That's true for all editors. (I compile from Mercurial though.)
I agree with you. How they work on a guest machine while connecting to them via ssh ? They're can touch their gui icons ? I don't know...
To your first point: usually I edit already created files. In these files after I open them, very very rarely I am at the place where I want to start writing something. So I need to navigate to the place of my interest and vim-mode so far always bested other editors.
Triggered!
I don't have a stance on
the general push for vimsince I don't believe it exists. Not sure I get what that means.variety of flavors Vim comes in- Vim or NeoVim? GVim? again not sure what you mean.you'll need to expand your code completion, syntax highlighting, and add additional functions like compilation- no actually you don't need to do that at all. You can if you want or you need that type of support. Personally in the teams I have been a part of and lead, reliance on IDEs can be taken too far to become a crutch and can inhibit understanding on what is going on in your codebase.I have been doing development for over 20 years. I have used a lot of editors and IDEs over the years on a lot of platforms and I have settled on Vim as I like the feeling of it and I have the ability to optimise my workflow with it. Editing at the speed of thought is pretty close to the truth for me. It feels like playing an instrument, if you will, and similarly the more you do it, the better you get and the better it feels.
Vim is the fastest keyboard driven language for editing. It's not an IDE but you can add in IDE style features if you would like. There is a reason for there being Vim plugins for most IDEs including Emacs the best operating system without a decent editor. If you don't want to mess with configuring Vim much you don't have to. NeoVim out of the box has some pretty sensible defaults.
Have a watch of some of the destroyallsoftware.com screencasts to get a feel of what that looks like.
what about adding vim's keybinding in <your-favourite-editor>
I think I forgot to escape <
Sure, if that works for you and maybe that can be a good softer introduction for some folks to Vim and modal editing in general.
yep.
I like the idea of working solely on a keyboard, but I don't know if I'm convinced that Vim is the best solution. I've been working on a "regular" editors like Atom and VS Code ever since I started programming, and I haven't seen a need to move to something as hardcore as vim.
Also, the fact that it seems "hardcore" feels burdensome and heavy to me. Tools are supposed to help you be more productive, and while there's a learning curve to everything, I think it what you said is true:
The one thing Vim does better than Atom and VS Code is performance. Even a GVim with a dozen of plug-ins feels snappy when compared to those.
But then again, so does every other non-JavaScript editor...
Ehhhhh I would agree with this for most things save ruby.. specifically ERB files. I have super performance problems that I've never been able to solve, tried all kinds of stuff, but nothing I can think of works, Vim's fine with most things but Open an ERB file and vim begins to chug.
Have you tried
vim -u NONE?I was able to narrow it down with debugging, it only slows down in erb files, it's fine every where else. I believe it to be an issue with the regex for syntax highlighting.
If you think syntax highlighting is what's slowing it down, then you need to try to load one of the problematic files with
vim -u NONE. That command tells vim not to load any config and thus vim launches in vi compatibility mode. If it it's still slow, then it's not the syntax highlighting and the problem is elsewhere. For example, vim doesn't take too kindly to files that are absurdly huge (>5MB) or have absurdly long lines (>10K columns). But the thing is, that in itself is way better than all the other text editors, which choke on files much smaller than the ones vim chokes on. You should isolate the problem before spreading something like this; you might be spreading misinformation.I started out learning Vim because I had to regularly modify files on production systems that didn't have a IDE option installed. Now I use it because I'm comfortable with it and really like it's speed.
VimAwesome is a fantastic resource especially with the plugin/plugin manager issue. I've switched back and forth from a couple of different managers and haven't had any troubles.
I've tried most of the big name editors, each for a reasonable amount of time, and they're good. I always come back to Vim, though.
It's nice knowing that Vim will be on pretty much every system I log into. If it's not, it's usually no trouble to get it installed. It's fast and I think the movement keys are great. You can customize it as much as you want to and get some really great features.
I'm on the fence about this as well.
I think every developer should at some point install Vim, try out a bunch of plugins, and run through some tutorials — even if it's just so you won't feel scared when you end up within the editor by accident.
But more productive? Complex editing tricks often require a refresher in the form of a few internet searches and a bunch of experiments. You tell yourself that it's investment in future productivity... But obscure key combinations are long gone from my muscle memory when I need them again.
I love Vim as an editor, and use it out of habit when editing configs, markdown, latex, and bash scripts.
For larger code projects I personally prefer the Jetbrains IDEs, as they offer great out of the box smartness tuned to specific languages.
I am vim user and I have tries to switch to other editors and the main thing that makes me switch back is the lack of the leader key in vim mode for any other editor out there. I have my key strokes that "save me time" intiated by the leader key. I just cannot find an editor that will allow me to do that without being another time sink to setup.:-)
In my experience the one thing that Vim got right was keybindings and mapping. Modal editing does take away many pains of editing and does make you faster.
However, where I found Vim severely lacking was basically other things like:
My current setup consists of Sublime Text 3 with NeoVintageous for Vim like editing.
I believe it gives me the best of both worlds. Vim like keybinding and modal editing with all of Sublime's sublime features.
tag search, see ctags
fuzzy search, see fzf
multiple files, yeah it can do that with :buffer
vim's use of the unix philosophy to use other command line tools for extending features without bloat is another thing they got write.
I used all of those methods.
But modern editors such as Sublime and VS Code still provide a much better experience in those categories.
well one is more than welcome to use what they like. but please give examples of how x is better than y.
in this case, fzf and ctags also work with other tools out of the box so my email (mutt) client, file manager (mc), chat (bitlbee+irssi), and others has fuzzy search and tags. With that whole environment portable to thousands of machines online via git clone or docker image instead locked to one desktop.
Far and away better than VSCode especially on code bases with a lot of files - the command t plugin for Vim (I personally use fzf on smaller code bases) happily works across millions of files.
I got started with vi on Sparc 5s (and less!) in 1996 or so, and over the decades have accumulated a 200-line .vimrc file. I do not use it for every purpose, using VS Code for most of my coding, but I do use /vim?/ for a few special purposes.
font-sizeis set. I'm sure it's available in Code, and I think I have it set for one of the systems I use, but it isn't built-in so it isn't consistent. I go into visual mode and get it done.vi file.confand get out.Honestly, I could easily get my .vimrc under 100 lines -- maybe less -- without losing any of the functionality I need. A lot of it is taken from people like Damian Conway's vim settings. See Damian Conway show off vim at OSCON.
My problem is the same as the users who don't use it often: it would take time to determine which things I use and need and which things I do not, and it is easier to just go forward with things as they are. I was strongly in a sink-or-swim environment when I learned vi, surrounded by lots of people with similar knowledge but knowing just that keystroke that I needed to move forward. But the space I work in is somewhat anachronistic in the coming cloud world.
I would gladly wear a t-shirt with the "Oh Ned! You Are a vi man after all!" image on it, but honestly, if I could trade my not-ready-for-git-or-other-revision-control current codebase for something where I wasn't developing in production (It existed like this before I got here) and all it would cost me is my vim knowledge, I would trade it in an instant.
I don't know about the editors themselves but I'm pretty sure that Vim key bindings (which is available for many popular editors via plugins) will make you (hopefully) more productive at editing text which increase the productivity of developing code since it requires typing a lot.
Even though I struggled quite a bit at the beginning of learning Vim and Vim key bindings, I highly recommend every developer to try to be comfortable with Vim key bindings and enjoy their faster code editing with less typing for the rest of their coding lives.
About productivity:
Vim does not have to be a sink of time. Configuring plugin is easy most of the time. What take time is configuring it for your needs. Let think about it: if you configure it because you are annoyed to not be able to achieve some tasks, it means that you configure it to gain time.
Every time I install vim on a new computer I just clone my dotfiles from Github and I have everything configured. I used PHPStorm before (good old bloated IDE) and it was a pain when I was reinstalling my system or even upgrade the damn thing.
Nobody knows how to measure the productivity difference between somebody using Vim or an IDE. Going in one sens or another is useless to me without real data anyway.
At the end, Vim is fun. That's why I use it ; to me it gamifiy coding itself. This is the most important to me.
And you know what? I'm more productive if I have fun.
For those interested to know how and why used Vim instead of an IDE (in that case PHPStorm), I wrote a blog article about it: web-techno.net/phpstorm-vs-vim/
I truly and objectively believe vim does make me more productive. Some other stuff not necessarily related to text editing are way more important, but since I'm willing to pass a lot of time of my life coding, investing in optimizng the text editing process is really important.
While editing text, before vim I've noticed what takes the most time is figuring out how to do what you want to do in the minimum amount of time. Vim solves that problem beautifully, at the cost of being hard to learn. It comes to a point vim makes you spend less time thinking
I feel vim is like learning a new language, it's hard at first but once you master it you don't even think about it and do everything really naturally and fast, whereas previous text editors felt like using Google translate everytime I wanted to express myself.
It really comes to this: optimizing your process to the point you don't even need think about it, it all comes naturally to do boring stuff fast. If the tool you use is impairing you from getting to that point, maybe it's time to change tools. That's what happened to me.
But text editing is just a fraction of the big picture. Planning well your code - and your day! - beforehand, knowing how to better navigate through code to find fast the information you need, improving readability and designing an architecture that allows you to make changes easily are more important, specially because it might affect the overall productivity of your team.
I both agree and disagree with this post. Vim doesn't compete with the capabilities and tighter integration other IDEs have but affords you the flexibility to customize the experience with the many off the shelf plugins and tweaks, etc to make it your own for your needs - that's harder to do with the all-in-one competitors and where it is possible, you are boxed in and limited. Have a new company DSL that has custom dev/test work flows and complex integrations with git? OK, write your own nominal syntax/plugin, hook in with vim autocommands that run custom tests in the background, have fugitive manage your git CI/CD,etc. Overheads? Sure. But manageable. Take vim away from me and I'm paraplegic. Give me something else in its stead and I'm dysfunctional.
I think I'm echoing some of the other comments here, but I was intially attracted to vim because I wanted to be a power user. I have probably spent weeks worth of time customizing and tweaking it, even picking up a little vimscript along the way. My life got tremendously better when I stopped trying to make vim "perfect". I reduced the number of plugins I use (no completion needed with default control p and n, no syntax highlighting, etc). I wanted a universal tool to help me write code that didn't get in my way.
So while vim itself didn't make me a better programmer, it certainly made me appreciate the "right tool for the job" mindset. I think vim is one of the best text editors that you'll find, but if you want more, well, find what works best for you I guess