loading...

Vim: from foe to friend in 9 minutes

omerxx profile image Omer Hamerman Updated on ・11 min read

Lessons from 3-years of intensive learning

TL;DR
Using Vim is by-far the most productiveness-enhancing, enjoyable and rewarding tool you’ll ever adopt. This post was an idea I had for a long time; there are literally endless pieces of information about Vim out there, and every time I started writing I thought I was just adding to the chaos. I feel it became too important to ignore, too much of a productivity change, and probably the best tool I have ever decided to take upon learning, and so I’m sharing my process. This is an opinionated post about how I think anyone should start. As I usually prefer to get solid procedures and actual action items, this is what I tried to create here so readers don’t lose themselves in the sea of information out there.

For years Vim was a stranger to me. In one of my first job interviews as a junior, the recruiting manager wanted to test my limited set of skills and asked what my favorite IDE was. My answer was something like “Notepad++”. Needless to say, it wasn’t quite what he was expecting.
He dug further and asked, “What do you think about Vim?”
I replied: “Vim?? isn’t that this console thing no one knows how to exit?”
Long story short, I didn’t get the job…

To me, Vim was this CLI editor sysadmins used in videos and a kind of a hack-tool used by hipster developers around the world. “Why would anyone do that to themselves?” — I asked myself and others more than a few times trying to understand whenever I met another enthusiastic user. I genuinely wanted to know why are people talking about it so much, why would anyone use it? How can anyone be so motivated to use and improve their flow with Vim continuously when it’s such a terrible tool to use.
What’s wrong with modern editors?

So I tried it out. A lot.
I took vim for many, many test drives. I wanted to prove to myself I could use it. It was my nemesis and I would not accept defeat. I got to a point I made up my mind that Vim is a religion. There’s a bunch of people who believe in it with all their hearts and just the same amount of opposers, like me that couldn’t see the light. So I left Vim aside, but couldn’t help keep thinking about it as I kept noticing other professionals across dev communities speak so highly of it. Heck, even on Silicon-Valley [s03e06] the fight is over spaces vs. tabs and Vim vs. Emacs. “Really?” I thought, “Vim vs. Emacs?”, people don’t use *standard *editors?

The real change happened when I met one of the most talented backend developers I had ever worked with. He was so enthusiastic about Vim, had so much knowledge, and most importantly worked so freaking quickly and smoothly I had to know what he was doing. This leads to the beginning of my “why”…

Why

  1. Vim is always there on any *nix machine, Mac and soon even Windows machines. You can always find it running natively on your OS. Vim (or its predecessor VI) are already installed, so even if you’re not going to utilize it for everything, you probably want to know it pretty well. You want to be able to find your away around remote-servers-editing quickly.

  2. It’s productive
    This is the holy grail of using Vim; once you master the basics, you’ll become so ridiculously fast, you really won’t able to go back. You’ll start looking for those quick moves when writing messages or when chatting online. Writing any code or editing blocks of it becomes smooth and fluent in a way you probably never knew possible.

  3. Integrations
    Vim is so powerful it has integrations with just about anything you can think if. I don’t even leave it to git commit, push, browsing through history and what not. Took it one step further and created my flow of solving merge conflicts right from Vim!

  4. Awesomeness
    Not sure if I should address this as a real factor, but being honest, Vim is an enjoyable tool. Every time I use it, including when editing these lines, I enjoy my shortcuts, movement abilities, macros, and repeatable commands.
    Think of yourself in the office using it; your colleagues are going to be so impressed they’d start asking for resources and tips. I know because that’s how I started and how other colleagues of mine started after me. We all can say the same thing, after reaching a medium proficient level: you become so freaking fast, other editors stop making sense. You can think fast, work quickly, and never feel an idiot again.

  5. It’s right
    Hands down, how many times did you find yourself editing over 20 locations in a single file, reaching for your mouse over and over, knowing in your heart what you’re doing is either wrong? How many times did you feel like you were wasting time on reaching UI buttons or looking for the right click to help you make the change? For me, the answer was dozens if not hundreds of times, until one decided to put a stop to it.

  6. It’s light; it’s so light it takes 10% of your machine’s resources. Check out the comparison below describing average memory consumption of popular IDEs:

A comparison of VIMs average memory consumption taken on multiple Linux serversA comparison of VIMs average memory consumption taken on multiple Linux servers

How

Honestly, Vim is not the most accessible tool to adopt. Hell, it’s hard.
Vim has a very steep learning curve, but rest assured: if you try, don’t give up, and be consistent, it’s 1000% rewarding.

Time vs. Productivity of IDEsTime vs. Productivity of IDEs

The visual above is a simple demonstration of my learning curve experience. With any other IDE, I became semi-productive quite quickly (“semi” is only said in retrospect after knowing what Vim can do..). However, the green Vim curve shows my starting struggle which, after a while turned into an incredible skill.

How did I do it?

After a few brutal fights where I returned to my fallback IDE with my tail between my legs, I made a decision to actually LEARN Vim. Here’s how I did it:

  1. Got a nice small notebook I could carry around

  2. I bought the awesome Practical Vim by Drew Neil both in hardcover and for my iPad to read on the move

  3. Every night before going to bed, I read one tip — the book is very intelligently built like that for easy, slow studying

  4. The IDEs on my mac were removed, no more VSCode or PyCharm's arms to run back to. It was Vim alone

  5. I’ve signed up for “Mastering Vim Quickly” newsletter and followed them on Twitter, where I was constantly learning new tips

  6. I’ve started my online list of tips I learned and picked up on the way, which I maintain to this day
    Talking about new tips, they are endless: even after years of work you’ll find yourself applauding another feature you never knew of. Vim is an infinite jar of candy

Rotating the joke on VIM… don’t quit the fight; it’s worth itRotating the joke on VIM… don’t quit the fight; it’s worth it

Gradual learning

After a few days of reading, I slowly started getting the grasp of movement in Vim using the famous hjkl, and learned to search and save keystrokes. I began understanding how Vim operates. What's the fastest and most elegant way for doing every single change. I started finding myself getting out of bed after reading a tip to try it out and writing it down in my notebook.

Diving right in may not be for everyone. If you’re not yet willing to drop everything else and use Vim alone, you may want to try out some excellent integrations for IDEs; a popular one is VSCode’s Vim mode which adds most of Vims functionality and abilities right in your beloved (and soon to be ditched 😉) IDE. I tried it and had a hard time finding 100% of the functionality I was used to, so I went straight back to full-on Vim.

When

Funny question to ask, but — right now. You may be launching a new project or starting a new job; these are just a trigger to adopt a new life-changing tool. Nothing has to be dramatic; you can pick it up as you go. As long as you’re consistent and determined, within a few weeks, you’ll get to the point discussed earlier where no other tool is required anymore. You'll be past the point of just being productive: you'll be faster in vim than anything else.

Who

Jokes aside, mastering Vim is a life changer for any writer. Yes, it’s designed to edit code, but I got to a point I’m writing my text there since I feel more confident, productive, and comfortable. Here’s a nice piece: “Vim for writers”.

Whether you’re in IT, DevOps, full-on developer, the occasional script writer (and scriptwriter 😁), or data analyst: everyone can use Vim and enjoy it to the max. I got to write Python, Golang, Crystal, TypeScript Bash and a lot of text (these lines right now, for example). There's no text editing situation I can think of for which vim is not a perfect solution.

Customizing

By now, you learned that Vim is one of the most versatile, customizable tools out there. Not only it has endless plugins, but you can also change your configuration file (the .vimrc) and can pretty much change everything. Having that said, you may want to start Vanilla. Here’s a good video that can save you a lot of plugin installations just by knowing Vim’s built-in abilities. The one thing that is recommended to use is Tim Pope’s Vim-sensible plugin.

Plugins

Having one of the largest enthusiasts communities out from there, Vim has endless plugins, most of them can be found on GitHub. A word of warning though, while plugins are helpful and enjoyable, they have a few downsides with them:

  • They’re heavy on Vim: you may notice lagging and longer response times with some highly demanding plugins

  • They may be conflicting with other plugins/configurations: (usually, you won’t notice that with popular plugins)

  • They’re masking some of Vim’s abilities. You install a plugin that has pretty good vanilla functionality in Vim already — Check yourself before running to every shiny plugin

  • They may be slowing down your leaning, adopt them with care, slowly, and only when you feel the need

Here’s a rather short list of plugins that I use (I try to maintain them by removing the ones I don’t use anymore occasionally). you can also find the full list of them together with my .vimrc on GitHub.


That’s it, and thanks for making it this far!

I hope this post helps you get started and find your way towards an enjoyable productivity change. I know the internet is full of information and ideas, but since I had to figure out for myself what works best, and made it only after a few attempts, I thought of sharing the process with some other people looking for some guidance. I hope you enjoyed reading and will share this with anyone looking to make his first steps into Vim!

Big thanks to fuzzymidget Reddit user who offered his help with styling and language corrections, commenting on my post on subreddit r/vim.

I invite you to take a peek at my own .vimrc configuration, suggest changes or take ideas.

My name is Omer, and I am an engineer at ProdOps — a global consultancy that delivers software in a Reliable, Secure, and Simple way by adopting the DevOps culture. Let me know your thoughts in the comments below, or connect with me directly on Twitter @omergsr.


Edit [July 5th]:

With his permission, adding @russellbateman 's comment which gives another angle and some insights I couldn't have come up with on my own:

I have used Vim/vi for 35+ years. One problem in the (rather religious) discussion of editors is that folk only compare editors. Vim/vi isn't merely an editor; it is a full, raging text processor! Mere editors, even really fine ones like Notepad++, typically don't walk very far down the road of text processing. They're present as editors only.
Until comparatively recently, IDEs that offered vi compatibility really only offered the skin-deep face of modeful editing--that part of vi that is what puts people off. They did not offer .exrc or .vimrc support nor keystroke power much deeper than the mode. A lot of people were and still are left perplexed as to why anyone would ever be masochistic enough to learn Vim/vi just so they can switch it on in their IDE.
Fortunately today, while exhibiting some annoying practices in terms of integration, first-rate IDEs like JetBrains IntelliJ IDEA offer more complete Vim integration than the silliness early IDE attempts made two decades ago. Personally, and because I grew up a UNIX command-line guy, I am not the least bit bashful about popping up a console outside my IDE to run Vim/gVim even though I know that IDEA's vi emulation is probably up to it.
Last, I generally never install any plug-ins despite recognizing their utility. I'm not hostile to plug-ins, it's that, just as vi/Vim is everywhere nowdays (and the only game in town on freshly brought-up Linux systems), plug-ins are not ubiquitous, so I don't even think about them until I'm doing something really specialized, not a frequent situation.

Discussion

markdown guide
 

Thank you for this article, and congratulations on having had the courage to take several years to get a grasp of vim.

I am very sensitive to my productivity, so anything that can make me faster makes me very interested. To give you an example, I almost never use the mouse, I use keyboard shortcuts as much as possible.

Sadly, after reading this article I still don't get what Vim can bring me, that my IDE cannot. I still don't see how it can make me faster.

Could you please share some concrete examples of things that vim can do, that IDEs don't? Or things that vim can let you do faster?

To give you examples of why so far I don't have this answer:

  • text navigation: in any text editor on my Mac, I can use Option + Arrows to navigate word by word, Cmd + Arrows to go to beginning or end of line, or to beginning or end of file. I can use Shift + Option + Arrows to select text word by word and Shift + Cmd + Arrows to select the rest of the line, to beginning or to end. Additionally, using Cmd + F I can search for a word and navigate there directly.

  • repeated typing: in my IDE, I hit Cmd + Option + R on a class' field, and it refactors it everywhere, not only in that file, but everywhere it's used in my project. In most text editors, I can type Cmd + H or Cmd + F, and it replaces all occurrences of a word by what I want. In my IDE I can provide a regex for that.

I even find that these shortcuts are more handy than in vim, because I don't have to reach for the Escape key, my thumbs are already on the Cmd key, my hands don't need to move much.

To avoid any misunderstanding on my question:

  • I am not saying that I am not interested in being faster, or that this is not important. I think this is extremely important, and I would love to be able to be faster. What I don't get is how vim can make me faster
  • I am not interested in things that vim can ALSO do, same as an IDE. I am sure that everything an IDE can do, vim can do too with a plugin. Only this doesn't interest me. What interests me is what vim can bring me that is BETTER than an IDE.

Thanks a lot again for this article, and thanks in advance for your clarifications!

 

Hey! And thanks for raising the discussion because there are great questions.
I'll try to answer to the best of my understanding.

There is no claim that IDE's as a general concept are all inferior and cannot do what Vim does. Vim has a very profound concept of motion that is designed to make you faster.

For example, you mentioned the motions you use when moving in a line. In Vim, while it's obvious your mouse isn't playing a role at all, just reaching for your kb arrows is considered a big no-no. The motion is designed to keep your wrists in the exact same position, while only moving the tips of your fingers. Arrows are considered a complete finger context switch. And so motions are being used with hjkl (hard to get used to, but once you do you won't go back to taking your fingers away :) )

Another point in the motions you described in the first question is only involving a specific line. Try to consider moving in a large text file (or a code file for that matter) where you have to jump between definitions or methods. Vim always tried to involve the shortest way such as typing <number of lines>+<down motion (j) or the use of marks. The same goes for the Vim quick search and navigating between results with motions that won't draw your fingers away. You can even take it a step further and use the motion plugin.

Another powerful motion is f (find) and F (find backward) which lets you find the next char in front or behind the cursor. And so moving to the next space (or next 3 spaces for that matter) are a chain of number and find motion. This goes for anything and is one of my most used motions in Vim, which when writing text in another editor (like at this moment for instance) I find it very hard to use without my superfast options..

If you're really into learning it you can try reading the docs or reading the matching section in Drew Niel's book (mentioned in the post).

When it comes to repeated typing, Vim is super useful, mastering macros allows a super-efficient way of refactoring code and custom changes where a simple multi-cursor concept won't do (which by the way Vim implements really nicely too).

To conclude I'd add that Vim's idea of doing stuff is a number of repetition followed by a motion followed by a target (char / word / line / code block / page etc...). If you know how to handle even a few it makes you a wizard of motion and efficiency.

To me, it was the difference of translating my thoughts into code (or text) in the same speed my mind works. Which also contributes to the flow of work and creation.

Hope this helps or answers your questions :)

 

Thanks a lot for taking the time to address my questions.

This reply helps a lot. I start to understand some of the benefits of using vim. Not having to move my wrists can definitely speed up things tremendously.

Could you please share an example of "mastering macros allows a super-efficient way of refactoring code and custom changes where a simple multi-cursor concept won't do". I still don't have a good picture of what that can be.

Thanks a lot again!

Hey Vic,

Sure: imagine a situation where you write some javascript code and would like to change them all to async and add an optional parameter to them as well.
With any other tool you'd have to go one by one, maybe you'll be able to search for function and maybe be able to add the prefix of async but how about a last optional argument?

With Vim the logic for a macro would be this:

  1. Search for all functions: /function
  2. Start recording to a specific register:qq means record to register q, qw - the same for w
  3. Add a preceding async: I async <space> (cap I means "insert at the beginning of the line)
  4. Go to normal mode: <esc>
  5. Find the closing arguments line by f) (*f*ind forward the char ))
  6. Insert the argument: i somearg? (*i*nsert the arg with optional ?)
  7. Go to normal mode: <esc>
  8. Go to next appearance of function: n
  9. Stop recording: q

Now, if you @q Vim will perform all of the above on the second appearance of function and will end on the next one. if you @@ it will do once again the last used macro.
If you 50@q you'll run this 50 times more. Assuming you have less than 50 of them, and that function is generic enough in JS to indicate a function and will not appear anywhere else in the file (in other case you have to fix your initial search target), you've quickly editted a file regardless of the size with the exact change you wanted.

While this may seem very specific, I can't stress enough how useful this is. When you deal with huge json or yaml files this is like a magic wand.

You can also combine this with NERDTree to visually walk through any other file (maybe even with specific naming) to edit multiple ones.

You can even edit your macro by reading the register q and saving it again (will not explain here unless you really want to dive into it) and use it later, or just fix stuff.

Thanks a lot once again for taking the time to share insights with me. I really appreciate it.

As you mention, I find this example pretty specific. I don't write JavaScript, so I wouldn't know about adding "async" to many functions at the same time. But I can't imagine when I would add the same optional argument to many contiguous functions at the same time. Do you have a real life example of some vim-specific refactoring that you did recently?

About processing large json or xml files, this has never happened to me, and I guess this is pretty rare for standard software engineers.

Don't get me wrong, I am not trying to argue here, or prove that vim is not useful. I am really genuinely interested in understand specifically what benefits it can offer me, and other typical software engineers.

Thanks again very much for your help!

Hey Vic!

No worries at all! I totally get you.
I think what's important here is that you learn what you need. If you don't feel you have repetitive refactoring work then there's no need for you to dive into it.
Macros in Vim are a relatively very easy thing to learn so I think spending the hour and adding them to your arsenal of Vim magic is a good thing.

I think I find myself using a macro once a day. Sometimes it could probably done with a regex replacements statement (%s/<pattern-to-replace>/<replacement>/g) and sometimes with multiple cursors which I find to be more dangerous then helpful.

Thanks again for your reply.

About not feeling that I have a need, I think one does not need to feel the need. Very often, one doesn't image that one could go faster. This is why although I don't imagine how I could be faster, I would love to get examples that I don't picture yet.

About refactorings, I never use multiple cursors. However I very often use IDEs' rename variable, rename field, rename method, rename class, move class, etc, tools

Hey Vic,

One example I used today: I'm building our product's backend and am testing it both with unit tests and mocks of calls and both with sending real-life requests from postman.

The request is a 100 line JSON, and we agreed yesterday about removing a specific nested field from specific locations in the request. I've created a macro that searches for the constant field about each set of actual fields needed deletion (/<field>/) then, I created automation for deleting it (this was specifically "go 3 lines down, remove the trailing comma, then delete the line below" since this should be a valid JSON). So: 3jEx (3 lines down, End of line, delete char), and jdd (line down delete line). Now, all I had to do is find the next (n) appearance of my search index, and run the macro as the number of nested objects I have (<#_of_objects>@@)

Thanks a lot again for your reply! I really appreciate your taking the time to share your experience.

I am not exactly sure, but wouldn't see be doable with a simple search and replace with regular expressions in an IDE? Something that would take a variable number of white space before your field, and an optional comma if the next character is not a closing bracket?

Depends, sometimes it is sometimes it isn't, regex on its own when trying to achieve complex solutions is hard.
Many times a macro is just a faster simpler solution which allows you to think like a human being, and sometimes the only way is a macro. Search and replace is a single specific use-case, not a substitute to all macro powers.

Thanks for the swift reply!

After thinking about all of this, my conclusion is the following:

  • I don't see how macros can change much my productivity
  • not having to move my wrists to the arrows, and using mainly the home row instead, is conversely a killer feature, which I can see making me a lot faster
  • the problem I have with switching is the following. Muscles only have a single memory. If I switch my muscle memory to vim, it means I will be very slow outside of vim. Which means either I have to go to vim every time I want to type anything, such as replying to each email, or I have to suffer frustration each time I type something outside of vim. If there was a way to change system-wide input settings to use an "embedded vim", I would definitely make the switch

I guess the situation is a bit the same as with switching to a Dvorak keyboard layout. I tried it before, and then I realized that I couldn't set it up on my phone, so I was super slow and frustrated on my phone. I moved back to a standard keyboard layout just because of that.

Hey Vic,

Basically I agree with the last 2 statements. With the first one not fully but I can only send you to the docs where you may find something I didn't say :)

About the "problem" with moving out of Vim, I agree but you'd be surprised to know that since Vim is deeply integrated a long time into any *nix system it's convention keys can be found almost anywhere. Even modern mail clients like SuperHuman integrated Vim shortcuts by default...

Personally I use the same for everything, even my MacOS desktops are configured to switch with Vim hjkl.

Another example is the terminal which can be set with set -o vi to provide Vim motions within the lines.

The same goes for IDEs obviously and many more...

Thanks again very much for taking the time to clear things out for me. I really feel lucky to receive such guidance.

One crucial point for me is the ability to use Google Docs and Gmail. I tried looking online but so far haven't found any really good solution. VimAnywhere seems to be good for short non-formatted input fields, but not very convenient with Google Docs.

Would you by any chance have something to suggest?

Thanks a lot again!

 

I've never used Vim, so I don't speak from experience. There is this one thing that has been bothering me for some time, and I didn't understand yet: if Vim is so awesome, how come no other editor has adopted some of its capabilities? As you mentioned, VSCode has done it (to some extent) but not to the fullest, just as a mode.
I mean, if some other editor\IDE would implement these awesome features, why wouldn't Vim users change their editor?

 

Well, it's a good question and I think it comes down to this:
Most IDE's want you to learn their language, syntax and shortcuts. They are all inherently adjusted to modern desktops using mouse and arrow-based keyboards. They want to lure you into using them and sticking with them with shiny features and colors.
Vim is hard. It takes time and effort, other IDEs can't afford to lose you just because they have a "vision" of how productivity should be.

On top of that, even if one of them were to adopt everything Vim does, it'll never be as low-resource requireing as Vim, and will never become a standard to be found on any Unix server to use...

I think that explains it more or less.

 

Vim is awesome, but he has the hardest learning curve. If you want to learn Vim you have to deal with frustration, if you can do that you can use the best code editor that doesn't set any limits.

VSCode, Sublime, PHPStorm and Atom all have their Vim plugins.

 

I agree with everything.
In regards to having a Vim mode in your IDE, personally I don't like it;

  1. I found it has its own limits (as expected) and you're missing some Vim essentials with any of them.
  2. Having the GUI available always tempted me to use it and not force myself into making Vim a second nature.
  3. I wrote about it, but the resource consumption IDEs like PyCharm or IntelliJ are using is ridiculous...

Combining these I decided to stay with Vim alone, and never looked back

For me, Vim is still a code editor, an IDE has certain advantages for complex projects. From this point of view it is better for my purposes to combine IDE with Vim Commands. Outside the IDE I work with Vim.

I don't worry so much about resources with the IDE, I use Docker for JS stories that eat more resources :D

Haha understood :)

Throughout my work, I found replacements for IDE features like static code analysis (Python and Go have some incredible Vim plugins for that), even a debugger with breaking points and everything.
Yes, in the end of the day I understand why some devs would choose IntelliJ with their entire environment pre-configured, hooked up to Git and what not, to me it looks lazy and not knowing what's under the hood (git / env vars / any other operational stuff) but who am I to judge what helps people write code and deliver...

 

There are a few interesting answers about that on this thread:

stackoverflow.com/questions/14410/...

 

I'll take the last half sentence of the accepted answer:

"Modal interface in the hands of an experienced and non-fickle person can be extremely efficient."

Meaning, on any other case you can harm yourself or get frustrated (Vim is hard), but with the right method and learning curve, you can become incredibly productive and satisfied.
But again - it takes work.

Absolutly, I'm a neovim user myself. Not an expert but after time I find "easier" working with vim/nvim than other editors. That stackoverflow thread is interesting because, in reality, modes and modal editors are precisely against every usability principle.

Hence the question - how do you explain the adaptation of vim and its modern progress?
And do you know any other modern IDE that comes close to its abilities?
VScode vim mode doesn’t count.. these are still vim modes in a prettier GUI

The key question here is, why do modal editors exist in the first place? In the early days of Unix before mouses were widely used, all the editing was keyboard-driven, from moving the cursor around the document to more complex operations, like string substitution.

This answer

if Vim is so awesome, how come no other editor has adopted some of its capabilities?

Because when mouses started to be widely used, there was no point in modal editors. But again, there is a reason why vim or emacs survived all these years, they are incredibly powerful.

As for modern editors, well, actually there is Oni.v2.

I get that, I do. But the thing is that while it isn't explicitly mentioned, mouses are convenient but are key in making us lazy, slower and thus less productive.
Heck, even arrows are "banned" in Vim...

So yeah, a mouse is easier, and if you don't want to learn too hard it's obvious why would you use it.
But for those of thus that care about productivity and satisfaction, it can't be achieved with other IDEs, no matter how familiar you are with their own set of shortcuts. In Vim it's a philosophy translated into concepts, rather than a few nice keyboard shortcuts.

This is all IMHO of course...

 
 

standards

This comic might be a good way to look at it.

 

Trying to understand whether this is generally about IDEs or about ways to learn it...
If it’s IDEs, well, don’t know if Vim can be standard but the concept can (and has) be adopted by similar tools. As said in the post, it’s not easy, it’s demanding and most people would drop it soon after they start. All I have to offer is look passed the terrible starting point.

 

The irony is that they have. EMACS has a vi mode. Apparently you didn't know that.

Look up EMACS viper.

Also bash has a vi mode. There probably are others.

So...basically they have.

 

If we're talking plugins autozimu/LanguageClient-neovim is essential!

I almost switched away from Vim this year after 10 years as the IDE features like code completion / goto definition / variable rename / type check / documentation preview were always lacking, or highly dependent on what language you're using, and siloed into separate plugins.

Thanks to Microsoft's work on the Language Server Protocol you can now use one vim plugin, the language client, and configure different external language servers for whatever file is open, while using the same key bindings for all the commands.

 

a. That's fantastic! I did not know this one
b. How is it compared to python-mode or vim-go ?

 

I'm afraid I haven't used it for either language, and perhaps being generic it will be less feature complete than something written per language. But I really like using the same plugin for Typescript and Flow-typed JavaScript.

I get it. Will definitely give it a try!
But if you ever take it with Golang or Python the two above are crazy-good.
Static code analysis in a level I've never experienced with any other plugin / IDE..

 

open terminal window and run

$ set -o vi

enjoy!

 

Oh this is one of my favorites! I even took it a step further and mapped my terminal with jj (which I use for Vim escape) to apply Vim mode (set -o vi). Awesome feature

 

Mind blown meme from Tim & Eric

From someone who couldn't figure out why "Esc-b" and "Esc-f" stopped working, thank you!!!!!!

 

You nailed it with this post about Vim!
As a long time Vim user I see its functionality as poetry. It moves you as you work with it. It inspires the way you work and see the tasks ahead. Its truly stays out of the ways as you craft your current thoughts into reality.

Thanks for reminding me that Vim is wonderful! 👏🏽

 

What an awesome comment to get!
Thank you for that, for being right and putting the essence of it in beautiful words!

 

Long time Vi/Vim/Neovim user here. 8+ years to be more precise.

I guess I was at every step of a Vim user already, from the fanboy to the it's just a tool person.

Some things are really amazing about this "simple" text editor. I'm still learning it even after so many years, there is always something new to learn and to improve one's workflow.

I would say the worst thing about Vim and it's steep learning curve is that it leaves out some many people... And the ones who are "allowed" into the club usually become such fanboys that is even hard to make critics to the editor. Been there, done that.

Nowadays I just try to be open about it and if people want to start I tell them to find a good reason, like feeling more productive, and not something like "feeling like a Hollywood hacker".

And then, to finish: How do you know someone is a Vim user? Don't worry, they will tell you :-)

 

I guess it can't be put better than that :)

 

I have used Vim/vi for 35+ years. One problem in the (rather religious) discussion of editors is that folk only compare editors. Vim/vi isn't merely an editor; it is a full, raging text processor! Mere editors, even really fine ones like Notepad++, typically don't walk very far down the road of text processing. They're present as editors only.

Until comparatively recently, IDEs that offered vi compatibility really only offered the skin-deep face of modeful editing--that part of vi that is what puts people off. They did not offer .exrc or .vimrc support nor keystroke power much deeper than the mode. A lot of people were and still are left perplexed as to why anyone would ever be masochistic enough to learn Vim/vi just so they can switch it on in their IDE.

Fortunately today, while exhibiting some annoying practices in terms of integration, first-rate IDEs like JetBrains IntelliJ IDEA offer more complete Vim integration than the silliness early IDE attempts made two decades ago. Personally, and because I grew up a UNIX command-line guy, I am not the least bit bashful about popping up a console outside my IDE to run Vim/gVim even though I know that IDEA's vi emulation is probably up to it.

Last, I generally never install any plug-ins despite recognizing their utility. I'm not hostile to plug-ins, it's that, just as vi/Vim is everywhere nowdays (and the only game in town on freshly brought-up Linux systems), plug-ins are not ubiquitous, so I don't even think about them until I'm doing something really specialized, not a frequent situation.

 

Wow!
These are some deep insights I'd be happy to add to the post's body (if you're in).

I've never thought about it in the extent you described, also for lacking the experience and familiarity with recent history I guess.

So first, thank you for that!
Second, you made me recall a very good Vim talk about using it "vanilla" - "How to Do 90% of What Plugins Do (With Just Vim)": youtube.com/watch?v=XA2WjJbmmoM

 
 

Congrats, great post.
I'd like to recommend checking this website vimawesome.com/ is a nice place to find plugins and this one vim-adventures.com/ to helping you get used to using the keys for navigation on the code

 

Agree with both!
vimawesome is a great source of knowledge.
Thanks for sharing and for reading

 

I think vim macro was worth a mention. Although it looks complex but it's so easy

 

@tsehori probably a part of the answer for your question. Assuming by "other" you meant GUI based IDEs, there are so many things they just can't implement.

And it's not like vim is not implementing other IDE's features. It has got almost everything you'd want from those IDEs in the shape of plugins.

 

I love macros and it's one of my most used features in Vim, but this post was meant to hook people up and help them get started, macros IMHO are too deep in.

Maybe they're worth a separate post though..

 

Actually I'd argue on that. It's as easy as :

  • record the key strokes with qa,
  • stop recording with q, and play with @a.

To repeat 10 times, play using 10@a

Well, yes, but the essence is not the manual keystrokes, it's how to be smart about composing the actual record sequence of motions.
Thinking about "least strokes", and "everything can be automated" concepts that Drew Neil describes in his book.

These are the important stuff.. anyone can just go qa and @a but you want to learn that it can be used with multiple registers, and then can be combined together, and you can edit it, and be very thoughtful about how to do fast efficient moves and records...

As I've said.. maybe an idea for the next post!

 

I was a sublime user for the longest time. Then I started working on a raspberry pi project and could not figure out how to install sublime, so I went with what would work on such a dinky machine: vim. Never looked back!

 

This is a beautiful tweet idea :)

 
 

Thanks for sharing!

I'd switch the last two with Practical Vim book, but that's me :)

 

'Vim?? isn’t that this console thing no one knows how to exit?'

Right. Or to put it into the cleverer way: you can create a pseudo-random generated character sequence by asking a person unfamiliar with vi to try exiting it.

At the same time: no. Plenty of people know how to exit it and did from the first time they used it (like me decades ago).

 

Better than vim in neovim. Vim but async (i.e. a lot faster) and with richer plugin support (the best is coc.nvim which us not supported in vim).

 

Actually, I'm a neovim user :)
Thought that this would be too advanced for people to take in.
My goal was to broaden the audience and get more people interested in Vim as an IDE other than getting to know it in depth.

Thanks for the comment anyhow, you're 100% right!

 

Great Article! One thing I would like to add is the value of practice when using vim. Vimtutor is a great way to practice the commands. Also, one great way to challenge yourself is by doing vimgolf challenges

 

Great Post!!

vim is definitely one of the tools a developer asks himself after learning it:
"how did I live so far without it?"

 

Awesome resources. Thank you :)

I was shocked also. Because the Practical Vim book's price is ₺126 in Turkey.

 

Not sure how much that translates to, but it’s available in a lot of ways.
My specific choice for this one was paper, that I could read and write comments on the pages to further play with later...
If you need help finding it let me know

 

Actually, I can read it in English but yes, I need to help to find it but should be a little bit cheapest :)

IMHO, some books always should be free or cheapest.

Anyway, Thanks.

 

I like taking notes, so I'm curious; what kind of notes did you write with the notebook?

 

Well, I use the bullet journal method (which is a whole other topic) and I also take notes as mentioned. Specifically, with Vim, I used to read a chapter or two, summarize a page on my notebook with what I've learned and then read it the next day and try the new skills I've learned. Does that make sense / answer the question?

 

Yes, that is exactly what I was curious about; did you have any particular activity or items that you wrote down. The mere act of writing reinforces learning and memory.
I would encourage you to describe your bullet journal activity, particularly any performance trackers that you use.

Sure, so the two are not exactly connected: I do use a bullet journal which helps to the simple fact I always have my notebook with me. When I read practical Vim, I used to memorize tips from the book and write them in my own words. Obviously it was the ones I wasn't aware of and felt were crucial. When the book talked about fundamental concepts like "movement" or "always the least amount of strokes" I wrote it down and the following tips (e.g. switching 2 characters or using / to move faster on a document or using vim marks to find your way in a repository of code). I didn't have a specific system, but the book is built in a way you can read single parts and just add them to your skillset. If you follow along and make sure you get everything, you get the small tips and the big ones in the order that makes sense and helps you grow your knowledge.

I hope this makes sense

 

It was more like a marketing post. There are many free and comprehensive online resources available for vim.

 

Yes, I agree.
I mentioned at the beginning that I hate over flooding information that already exists in the internet, BUT - I gained so much by learning Vim, and while finding the information I didn't really know how to approach it, and the immense change it had taken me through made me feel I have to share it with the world.

So yeah, in a sense this is a marketing post, although no one is going to make any profit from it, besides those who choose to learn, and maybe the author of the book for making a few more bucks (which I believe he deserves very much)

 

Thanks buddy 😄. Well motivated myself for using Vim.