How to Learn Vim: A Four Week Plan | Hacker News Reader

How to Learn Vim: A Four Week Plan

medium.com

171 pointspeterxjang103 comments

I've had a completely different approach to learning vim, which I wholeheartedly recommend:

- learn the bare minimum: up, down, left, right, deleting words and lines, stuff you do everyday

- DON'T just look for tutorials learn stuff out in the void, you'll waste time since you'll end up forgetting 95% of it. don't distract yourself. Screw four week plans, the basics you can get in an hour.

- work. write code/stuff. whenever you catch yourself pressing a button > 3 times (you know, left-left-left-left or something like that) THEN look for a better solution. you'll discover plenty ways to navigate around the code you're working with. find a new way, stop looking, start using it.

- happy? no pain points? good. keep using vim, wait until you find something you'd like to improve. look for a solution.

The point is... just because vim can do something, doesn't mean you need to know it. It doesn't mean you need to use it. It's a tool, it's optional.

The other point I guess is... stop worrying so much about if you're using something "right". Are you happy with your workflow? Good! That's what we're aiming for.

These plans and intros and guides... it's almost like they're meant to overwhelm. It's a damn text editor, you can use 4 commands and be happy. There are no rewards and no raises for "knowing" 60%+ of vim's feature set. And after the basic what, 20%? it's diminishing returns anyway.

One thing I don't get, how do you navigate with hjkl when you're in insert mode?

I've switched to neovim as my main editor months ago. I like it, but I still use the arrows to navigate, or sometimes the `w` to jump words and `10j` to go 10 lines down for example.

But I go in and out of insert mode all the time, and hjkl is not useful at all there. So I never use hjkl to navigate. Never. So how come most people use those as the main navigation?

Am I missing something?

Many people rebind caps lock (or another easy to reach key) with escape. This way they can quickly change modes.

Also, most beginners use insert mode too much. If you find yourself going into insert mode just to change a letter or word, try learning shortcuts instead (r for replace, ciw for replace word, diw for delete word, and other neat command combinations).

That was my initial thought. I do use r to replace one letter, and ciw or ci" to change whole things. But still, after all this time, I find it simpler to just go in insert mode and do 3-4 things, than think of combinations or commands for every single thing.

Maybe I'm too lazy to memorize them, I don't know.

But using hjkl is still too weird for me, even after using vim for more than 6 months. :)

I don't usually have this problem. On a dev machine I install a more featurefull vim. I think there's a difference in how "tiny vim" most distros ship with and other vims handle navigation. Seems like tiny vim is closer to vi in enforcing hjkl in insert. I'm sure some reading this knows more than I do about this.

> But using hjkl is still too weird for me

It's very natural to use j and k. When you touch type, "j" is your right index home base (I assume you know it but that's why there's a physical marker on "j" and "f").

I mean from a layout perspective. hjkl is in one line, whereas the arrows are not in one line, with "up" one line above "down". That's a muscle memory I cannot fight yet.

One of my favorites: xp to exchange characters.

x cuts the character under the cursor and p pastes it after the cursor. Net effect is exchanging the character on the cursor with the one to the right of the cursor.

You can do the equivalent lines with:

ddp

dd deletes a line and p pastes the deleted line below the current line. Since your cursor ends up in the line after the line you just deleted, this ends up effectively exchanging the lines.

You simply don't navigate in insert mode. Inserts are meant to be small most of the time. They are also the unit for undoing, so it's sometimes bad to have huge insertions.

Actually, they're not unit. When you type "abcd", then (without exiting insert mode) move left twice and type "xx" (resulting in "abxxcd"), then undoing once will leave you at "abcd".

You don't navigate in insert mode. This is why its important to have some alternative to esc. Personally I use alt-anyKey to exit insert mode and do that key command in normal mode. In some terminals, this will be the basic function. Using gvim or a more modern terminal will require manual rebinding.

jk are usefull for navigating lines, especially with 'dd' 'yy' and 'p'. hl are for navigating either within a word, or when dealing with a syntactic mess where the standard movements aren't very useful. Outside that, bwe and their capital variants are great. In text, so are ( and ).

Beyond that, I'd look into text objects. Things like ciw ca) or ci] are great for just doing what you want to do. (Change the word below the cursor, change an entire () expression, or change the inside of a [ expression).

> You don't navigate in insert mode. This is why its important to have some alternative to esc.

There's one that's already built in: ctrl-[.

I found remapping Esc to ‘jk’ (as a right-hander) to be solid gold. Index-middle fingers. Practically instantaneous: they’re already on the keys if you’re doing it right.

Yup, this mapping is pure gold. I also mapped jj in insert to save (and put me back into insert again). I'm not as good at remembering to use it though.

But don't do that when you plan to use Vim to write in Dutch. I've also tried 'jk' for a while and it worked great until I started writing some texts in my native language: 'ijk' appears to be a pretty common ending for a lot of Dutch words :)

These days I've mapped CAPSLOCk to ESC and super happy with it.

In Spacemacs (a vim emulation mode in emacs), if you type "fd" really quickly in insert mode it puts you back into command mode and then you can just use hjkl to navigate.

I assume one can set up something similar for real vim.

I think what you're looking for is Ctrl+O, which allows you to exit insert mode, insert ONE command only (e.g. 4k), and immediately enter the insert mode again

Normal mode is where you should be most of the time. Insert mode is something you go in and out of. Most people remap escape onto caps lock (OS level), use jj or jk, or use ctrl-[ (works well with OS level remapping of Ctrl onto cap-lock).

So most people re-bind Esc to something else. Then why is Esc the default "Esc" in vim? Shouldn't it be something else?

And for those who use caps-lock, how do you deal with getting uppercase letters depending on how many times you pressed caps-lock? Sounds impractical to me. Every "Esc" you hit will change to uppercase/lowercase. Right?

You rebind caps lock at the window manager level, not at the vim level. This disables it completely. This is actually a good idea whether or not you use it for escape. Hitting caps lock by mistake while in normal mode will make nearly every command do something different, sometimes only slightly, sometimes in destructive ways.

Usually you don't. Going in and out of insert mode is the right way to do it since it allows you to use the much more powerful movement and manipulation commands available in command mode. Map escape to jk or something and move between modes with ease!

you can still do ctrl-p ctrl-n to go up and down. but these are a bit limited.

it is a little painful when you have to do many minor text changes in quick succession.

and ultimately, this is what made me just go straight to emacs and i have not looked back since.

emacs may take some use to getting started, esp if you are on osx (rebind command as meta) but it gives you the best of both worlds. the choices are unlimited and you get to program your own editor you want it to be.

Repeating the previous command (.) handles most of the cases where I would do multiple small edits. Search and replace (especially with backreferences, \zs and \ze) handles most of the rest, and macros handle pathological cases. There's almost never a call for doing multiple small edits by hand.

While I would agree with this to get started, but it's always a good idea to be aware of possibilities beforehand and skim though them once so one knows that the solution exists for the problem being faced, what the solution looks like and where to look for it the quickest. So while i know I will forget the exact implementations of 90% all the cool stuff I can do with vim, but I know the possibilities when I have seen them once somewhere.

I remember feeling combinations of motions with edit commands were like the superpowers when I first saw them. I had to look them up again several times whenever I needed them to get it right. But once I got it, suddenly predicting them to edit text on vim transcended into fun territory for me personally.

Though for vim, I have found to adopt only one or two new things a week at max to improve productivity. Anything more and it used to get overwhelming, or i forgot about it anyways...

I agree whole-heartedly. I'm far from proficient, but my vim skills did increase dramatically when I just started using it. A lot of that was driven by getting a Digital Ocean droplet and not having many other choices. I could've used nano, but I figured it was time for something new. I mainly use it for editing config files and the like, but it's been a good experience.

If anyone's interested in learning vim, I'd suggest just using it anywhere you'd otherwise use nano. You don't have to jump in head-first and use it like an IDE for coding or anything.

I had good success by starting with the basics but also learning up front what every unshifted and shifted key on the keyboard does by looking at a cheat sheet. Then review every so often, picking a few to try to remember. Just knowing what is possible is useful, and the more keys you know the more precise your edits can be. Nearly every key on the keyboard is useful in Vim.

Exactly. I installed VsVim or ViEmu and went about my daily work. Played Vim Adventures, just a few levels. Every now and then I'd look up more. After a while, I couldn't imagine not knowing vim, and it's painful to watch other programmers edit text.

I also chose the 'full immersion' strategy to learning my way around vim. It was a lot less stressful than trying to memorize a ton of information at once, and I feel like I am retaining things I learn because I actually learned them because I needed them for one reason or another.

For anyone who is looking for a smaller vi tutorial (vi is the predecessor of vim), or just to dip their toes into the water initially:

Here's a short free vi quickstart tutorial that I wrote a while ago:

https://gumroad.com/l/vi_quick

With this tutorial you can learn some basics of vi (which is the predecessor of vi) and get up and running with it in an hour or two of practice. Learning vi commands (the subset that does not belong to vim as well) is useful because vi is probably more widely available than vim (since it is more lightweight and also comes installed by default with many Unix and Unix-like systems, and even some non-Unix-like systems. So, having vi skills in your toolkit, makes it possible for you to edit text files with ease on a very wide range of operating systems, without needing to learn a new editor for each one or every few ones.

I first created it for some colleagues of mine at a company where I worked earlier. They were Windows system administrators who had been given additional charge of a few Unix business server boxes. I wrote it at their request. They used the tutorial, and then told me it helped them to come up to speed with the basics of vi quickly, which helped them manage those Unix boxes.

I later published the tutorial in Linux For You magazine (now Open Source For You), an Indian print-format computer magazine.

Enjoy, and feel free to give me feedback via Gumroad or the email in my HN profile.

How to learn ViM: Stop reading articles about how to learn ViM, and start using ViM.

While I agree with this to an extent, I really feel that adopting any new tech/tool/language needs at least some motivation.

To that ends, I think the best programming tutorial for the absolute-stone-cold "what even is computer code" is 'Automate the Boring stuff' [1] as it gives clear examples of where a computer doing something is better than manually doing something. The best vim 'motivator' is this stack overflow post [2].

[1] http://automatetheboringstuff.com

[2] https://stackoverflow.com/questions/1218390/what-is-your-mos...

For me these howto posts is the method the OP used. YMMV, but feel free to cherry pick ideas that may work for you. I skimmed the article and found some useful info on tabletop that I did not fully understand. But agree the best way to learn is to just use vim !

Seriously. If you're completely new to vim, fire up vimtutor to learn the basics. From there, just start using it.

That's my thinking as well. I printed out a cheat sheet, pasted it to my cubicle wall, installed VIM emulation in my IDE (I still think this is the best route for those used to their IDE's, provided it's a good VIM emulator), and haven't looked back.

I've been using Vim as my primary editor (and vim mode in all my IDEs for something like 8 years)

In my opinion knowing what lots of keys do in a modal editor is not that different to learning all the shortcuts in say an IDE. I learned all the shortcuts to use Eclipse very quickly when I stopped using a mouse (I've never really liked using them and avoid them at all costs)

Pick a week where not getting a lot of typing out for time in won't hurt you.

Stop using other editors. You'll forge the necessary pathways to use it with the proficiency you have in other editors and then you can look up the 1% subset of the enormous features that will actually improve your workflow.

Isn't it difficult or limiting for you to try to navigate the internet without a mouse?

Lynx, baby!

https://en.wikipedia.org/wiki/Lynx_%28web_browser%29

Not everybody has perfect vision or motor skills.

Not OP, but 99% of the time it is faster and it feels better.

The only cases where I need the mouse are continuous interfaces (eg selecting an specific time in a video player) or restrictive and dumb webpage configurations (eg WhatsApp Web does noes not allow you to deselect the input box with the keyboard)

I use VimFX and I would recommend it. It takes 2 min to learn.

This is exactly what I do!

I've come to the same conclusions (I'm using Qutebrowser though).

Interestingly, I found that my tolerance for the inefficient ways of most browser UIs now stands out to me as much as editors without Vim-bindings annoyed me after a couple of weeks. Once I got a hang of the controls, I started missing them everywhere else (unfortunately I can't choose my tools at work).

There is a plugin for Firefox called Vimperator. I use it a lot.

Not really. All browsers have extension to enable vim key binding, so you don't need a mouse to navigate the internet.

There's an abundance of good vim tutorials, but as a moderate user, it would be much more useful if there was a plugin that reminded me how to do things more efficiently. I know how powerful vim is, but forget the shortcuts or how to use them.

For example, when I navigate words using H-L, remind me to use W-E-B instead. When I navigate many lines with J-K, remind me to use number shortcuts or G/gg. You get the point.

For me I'd like there to be some "convention over configuration" package for Vim, especially with some modern shortcuts.

I don't have Vim muscle memory so the aged shortcuts don't really offer anything for me. For example 0 goes to the beginning of the line, while ^ goes to the first character in the line. Why can't 0 be the "default" first character shortcut?

Anyways I know there is a lot of Vim veteran out there that wouldn't want to use a package like this, and already have their own shortcuts made through years of configuration. It's just that there are hundreds of papercuts that would take years upon years for me to figure out and solve, instead of just learning.

I'll just continue to use Sublime...

I kind of felt the same way about Vim. I was very happy with Sublime. I still am and most of what I've done with Vim is replicate the functionality from ST.

If you're not curious enough to dive in full time then stay with ST.

I had the following reasons for switching:

* it's open source

* even if it is just 1-2% improvement that's a benefit you'll have every day for years - there's no guarantee but I wanted to see if it does help

* as it's a command line tool it feels like you're closer to your code

* you obviously get benefits in your SSH sessions

* it does kind of feel like wearing a tailored suit, you set it up exactly the way you want it

* I should be able to do everything that I could do in ST in Vim but I don't think it's the other way round

Do you mean h-l? H-M-L are useful (top-middle-bottom of the window), but not to navigate words.

By the way J (join lines) and K (look up the current word) are also useful.

There's this plugin [0] that will not allow you to navigate the file by smashing the keyboard. Essentially what the plugin does is disable the hjkl and the arrow keys for 1 second after you type one of said keys. There's also the extreme version of this plugin [1] which will disable the hjkl and other similar keys entirely.

[0] https://github.com/takac/vim-hardtime [1] https://github.com/wikitopian/hardmode

GVim has the shortcuts next to each of the menu items. GVim is the most newbie friendly environment which you can wean yourself off of once you're comfortable using Vim's commands.

> Week 4: Compose Vim commands with verbs and nouns

Really? I discovered and abused this week 1, it's way too good, and the main reason I switched and stayed in vim. I would think "delete around word" and hit the keys, or "yank inside (", it works too well to be a week 4 feature to use.

Being able to do more with your text editor is one reason to learn vim, and it's the theme I see over and over in these "learn vim" posts. But it's also responsible for the idea that, in the words of the article, "learning vim is a lot of work." It's just not true that learning vim is a lot of work -- learning to do a lot of things with vim is a lot of work. But basic hjkl navigation, switching between normal and insert mode with i and ESC, saving and exiting with :w and :q, deleting text with x and dw, these take a day to learn, tops. Learning the basics pays off right away, but it doesn't pay off in terms of being able to use advanced features. There's an alternative reason to learn vim that I never see anybody mention.

Vim allows you to think less about your text editor. Once the basic editing commands become automatic, vim puts the least friction between your brain and your text. No mouse, no arrow keys, your fingers mostly don't stray from the home row. (Especially if you learn to use ^[ for ESC.) It's as big a gain as learning to touch-type. The productive insights accumulate with time. It really doesn't matter to the beginner that dw composes a command and a motion. It deletes to the start of the next word, and that's enough for now. The idea that you don't actually know vim if you don't understand its grammar is ridiculous. It's like saying that kids can't speak English because they haven't learned how to diagram a sentence.

The whole "learning vim is super-productive but super-hard" narrative is just condescending ego-stroking from people who already know how to use it. I suspect it's actually discouraging people from learning vim, which isn't actually very hard. Half a dozen commands, and one crucial concept -- normal mode -- and you're off to the races.

It is super hard because everything you're used to from your regular editor or browser commands don't apply. So all your muscle memory is useless.

That might sound like it's easy to overcome but it's not and it's super frustrating until you get out of one groove into the other.

I think a huge reason people find this difficult is that it's being presented alongside a whole bunch of other ideas. Even the fairly minimalistic vimtutor goes off the rails after lesson 1. Most of the stuff in that tutorial could wait until you've been using vim for a month or longer. Learn the movement keys, learn to enter and exit insert mode, learn to delete text, and learn to save and quit. Trying to learn that and at the same time trying to learn about how commands are composed of actions and motions, or how to use plugins, or buffers, or regex, or anything else, is going to cause you to stumble over the basics.

I learned Vim by taping cheat sheets on the wall next to my desk. Whenever I wanted to reach for the arrow keys or do something new, I would look over to the cheat sheets and find the right command. Avoiding the use of arrow keys helps speed up the learning.

I work with several "Vim masters" who do about 50% of their development in Vim and 100% of their file editing there. It's extremely embarrassing to have to sneak and do repetitious file edits by hand in Notepad++ because I never invested the time into learning Vim. I tried reading a Vim book but became bored and quit after a chapter or two. Honestly I never worked with people who use Vim everyday before so it doesn't seem to be THAT common where it's a requirement to know it but I guess it's worth giving it another try.

Notepad++ does a few things I really like and haven't taken the time to learn how to do in vim. In particular, double click and highlighting a word and having the word highlight in the entire file, and then scanning the whole file by scrolling with mouse. This is stupid but I do it all the time when working with unfamiliar code bases.

FYI vim mode in emacs does what you describe.

> It's extremely embarrassing to have to sneak and do repetitious file edits by hand in Notepad++ because I never invested the time into learning Vim.

Nothing to be embarrassed of. Vim isn't the graal of editing and people are productive with all sorts of editors. Actually, I'm pretty proficient with Vim but I'm starting to wonder if it wouldn't be better to focus on standard mac os shortcuts. And I also believe that the best programmers are those that type the less...

Vim productivity has been overblown by the fanboys of terminal-based text editors, vim et al are sorta on the verge of being irrelevant even deprecated because there are two things that are getting better: modern languages and IDE's.

Vim/emacs existed solely because there wasn't anything better (lookup for ed, that's a real man editor) to develop on the old-days plus old-school languages have this trend of including tons of "ceremony" and "duck-tape" code for handling data that vim was good because the repetitive nature of those things while coding but those days are over, there are less jr's learning vim/emacs and those "Vim masters" you talk are becoming less and less irrelvant with every year, i expected that in the next 5 years vim will be talked as a thing of the past.

To some extent what you write is true of vi (there was nothing better when it was written), and vim exists for folks who are used to vi to get some features of an extensible editor (i.e., vim is an emacs for vi-users, just with a far worse extension language and fewer decades of debugging), but what you write is false when it comes to emacs.

The benefit of emacs is that it is a completely extensible environment for editing text. It turns out that just about everything we do on computers involves text: source code, sure, but also web pages, git, email, shells, configuration, UIs &c. All of that stuff is text, and emacs can handle it all, and it can be extended to handle the next thing which comes down the pike too[0]. emacs is the forever editor: decades after SublimeText and Atom are dead & gone, emacs will continue.

vi & vim will continue, too, because the textual language of vi is still more powerful than any of those GUI editors. It's more powerful than the default keybindings of emacs (although note that with things like evil-mode or viper, emacs takes on vi keybindings). Even GUI apps which try to implement vi(m) bindings generally fall down because they implement so few (in the same way that apps which try to implement emacs-style extensibility fall down because they use insufficiently powerful languages).

I don't know what editor the hip young kids of 2067 will be using, but I know that the folks getting stuff down will be using vi & emacs.

[0] vim can also be extended to handle anything, but compare:

    function! ToggleSyntax()
       if exists("g:syntax_on")
          syntax off
       else
          syntax enable
       endif
    endfunction
    
    nmap <silent>  ;s  :call ToggleSyntax()<CR>

vs:

    (defun toggle-syntax ()
           (setf syntax (not syntax)))
    
    (global-set-key "\C-cs" 'toggle-syntax)

Which would you rather write?

> Which would you rather write?

I get your point but I don't think this is a good example. This is the kind of thing you write one, put in your .vimrc, and then never have to think about again. Especially if you're putting your .vimrc in source control and pulling it down automatically into new environments.

The problem is that anything written in vimscript is going to resemble that first example, when were it written in elisp it could resemble the second.

Regardless, better to have vim or emacs than anything else.

> I don't know what editor the hip young kids of 2067 will be using, but I know that the folks getting stuff down will be using vi & emacs.

I have yet to met a developer that blame his inability to "get stuff down/done" because his editor don't let him write fast enough.

Developing isn't a who-can-type-faster contest is who can solve a problem in a fast and simple way, typing/coding is the thing you do _after_ you solve the problem.

> Developing isn't a who-can-type-faster contest is who can solve a problem in a fast and simple way, typing/coding is the thing you do _after_ you solve the problem.

You're right, and that's the thing: emacs isn't better because it enables one to type more quickly; it's better because it enables one to do more. With emacs, a developer can build out his own environment, and he can share that customisation with others. As an example, magit is by far the best way to interact with git. Another example is org-mode. Another is gnus. Another is notmuch. And on and on.

Indeed, it's this emphasis on extensibility which is why I prefer emacs (which is better-extensible) to vim (which, frankly, has a better text-manipulation language).

There's simply no competitor to emacs when it comes to extensibly interacting with text.

Even if SublimeText, Atom, IntelliJ, Eclipse, Visual Studio got perfect vi keybindings, I do not believe that they'd be as extensible as vim, let alone emacs. Since extensibility is the quality which enables a tool to be used for more than its designer imagines, and since no designer can imagine all his users' use-cases, I think that this means that SublimeText et al. will never be all one needs.

> vim et al are sorta on the verge of being irrelevant even deprecated because there are two things that are getting better: modern languages and IDE's.

I don't spend a ton of time coding any more but do spend a ton of time doing random text editing (properties files, XML, data manipulation, whatever). While I agree that modern IDEs are probably better if you're just doing straight coding I think there will always be a place for a high powered text editor.

Plus, if I'm editing a script on a remote host (random shell script) or just need to make a quick change to something locally then it's much faster/easier to drop into vim than to fire up an IDE.

IMHO vim for editing remote files it's still far too complex, i prefer nano for editing config files and write some tiny shell scripts. I do give you the reason when editing long xml files remotely, vim is superior on that but still i prefer to locally edit the xml file with a IDE because i have the possibility to visually collapse entries and automatically show syntax errors.

I know vim/emacs fanboys are going to say that all that it's possible on vim/emacs but still i have to invest time configuring those options and plugins on vim while on almost every IDE or even some simplistic GUI editor like Notepad++ those things come already configured and ready for work.

I'll echo the recommendation for surround.vim, commentary.vim and repeat.vim in the "Week 4" section. These are my most valuable Vim plugins. I'd add https://github.com/ciaranm/detectindent and https://github.com/scrooloose/syntastic to the list, but esp. Syntastic may already be to fat for some people's taste.

All of Tim Pope's plugins are brilliant. One that saved me a ton of pain was his Obsession plugin which stores sessions that don't conflict as much with other plugins.

Four weeks is a lot of time. One could learn many things in four weeks. Why would someone decide to invest so much time in a text editor. And, specifically, why this text editor?

https://www.norfolkwinters.com/vim-creep/

Just switched to Vim after a decade of using Emacs. The switch was one part of a larger life goal to simplify and embrace minimalism.

I think this shift in mindset was an essential part of being able to learn Vim.

In Emacs, I had dozens of plugins, and I could do everything so fast that I almost went on autopilot. This was great for boilerplate code that's 90% typing and 10% thinking, but not great for complicated code (Haskell, low level machine learning stuff) that is 10% typing and 90% thinking.

I don't understand why vim facilitates that workflow better than emacs. I have thousands of lines of elisp in my configuration files, but it'a all completely invisible if I don't call for it.

True, I could run a barebones [1] Emacs. But I want to align my use of the tool with the underlying ethos of the tool itself.

I think of it as being similar to CISC [2] vs. RISC [3], or Chinese characters vs. the Latin alphabet.

Emacs is CISC. It starts with a huge vocabulary of functions. If you intend to use it right, then you create new functions to add to the vocabulary. Eventually, it morphs into something that not even other power Emacs users can use. (The programmable editor.)

Vim is RISC. It starts with a small vocabulary of compose-able commands. If you intend to use it right, then you learn to make increasingly complicated sentences out of that vocabulary.

1: For some definition of "barebones" -- Emacs ships with Tetris inside!

2: CISC - Complex Instruction Set Computer

3: RISC - Reduced Instruction Set Computer

In that case you were doing it wrong.

With a touch of hyperbole you could say that emacs is there to do 100% of the boilerplate stuff for you so that you can spend 100% of your time thinking.

If that were possible, then I would agree. But in my experience, automating the boilerplate stuff just tends to expand the domain of what can be considered boilerplate stuff.

If I can rename a class across my project in 3 keystrokes, then I've automated it. But then I'll try out a dozen names before settling on something. Have I saved time? Perhaps I'd be better off thinking deeply for a minute or two instead.

It's kind of like how Powerpoint has actually increased the time that people spend making presentations. "Look! I can change the title font in one click!" <Spends the next 2 hours fiddling with fonts.>

Now we need article explaining the 'why' part.

I'm usring cVim for Chrome because that's a great wey to navigate pages.

And I've got a VS Code plugin for more or less same reasons. Just a couple of 'shortcuts' for when I need to work on a large csv file or something like that. But coding? No. Still can't get it.

Hmm, I might just take this approach at face value and do exactly as he said. I only did vimtutor a couple of times and nothing else. It only gets you so far. I really appreciate the survivability that vimtutor gives me though, I feel comfortable editing text in a terminal nowadays :)

I have felt that learning Vim, does have a direct relation to productivity, especially if you are more comfortable with keyboard interactions as compared to a GUI. And yes, the learning of this editor can be viewed as a developers investment into improving his/her productivity.

Everybody is bashing plugins but vim without:

- YCM - airline (I use inconsolata patched to have nice icons) - fugitive - Nerdtree - CtrlP - Utilsnips (I have some customs here too) - Syntastic (saved multiple times)

And other plugins (ruby, go, latex, gist) would drop my productivity considerably.

I believe that what helped me the most (I've been using vim for 4+ years now, but still not an expert by any means) is buying a keyboard without arrow keys and also, getting used to vim motions.

Vim motions are amazing. People don't use them. If they did, it doesn't matter what the plugins did, you can use motions with fancy stuff that plugins provide.

Also your argument against not installing an autocompleter is without basis. Just because vim can do it natively does not mean its good. The native suggestions are alright when I'm editing on a remote server but I use YouCompleteMe when possible on my own systems. People who are used to intellisense etc kinda need this to do their job and still use vim.

Back when I was in college in my intro to Unix class, I was introduced to vim as a text editor as part of the course and learned the basics. Over the next several months, I read through the getting started and editing effectively sections of the main vim help page and got up to speed.

In my opinion, just reading through the documentation and practicing is really all that you need. If you want to become an advanced user, then you need to always think if there's a more efficient way of doing something in the editor that's currently rather tedious and, once you learn it, practice and commit it to memory.

>Consider installing auto-pairs.vim

Personally I don’t like when editor puts something into buffer without my explicit command. Moreover, if you need autopairing, there is no need to depend on external script, just :imap ( ()<Esc>i

/Rant

Oh come off it! I hate this kind of elitist bull crap. Don't like editor putting something into buffer, do you? Do you have set ai in your vimrc? 3 guesses to what that does. How about set et? 'consent' you say? How is explicitly installing a plugin not expression of consent?

And as for your dismissive jibe about 'just imap' - auto-pairs is a bit more nuanced than that. For example it handles pairing quotes as well. Let's see your quick dismissive solution for that which handles closing quotes as well.

Why am I so angry? Well, because there are so many of these 'gurus' who go around being dismissive of other peoples preferences as tho their's is the only one true way. The comment could easily just have been, "I like to be explicit about entering my parentheses and even if I wasn't here's how I'd do it without a plugin ", instead of all that consent nonsense.

/End rant

Also auto-pairs.vim doesn't seem to break the dot command, contrary to the mapping they provided.

I have ~50 lines in .[g]vimrc for variables only, including ai, et. From the autopairing readme it is clear that it can do sophisticated things that :imap cannot.

Edit: I like to be explicit about entering non-whitespace, but have few imaps for snippets and formatting in per-directory x.vim files, to be clear.

Btw, I tried to use autopairing yesterday in sublime text 3. What I noticed that it is easy to get used to autopairing on entering lines, but when line is edited again, it often leads to unbalanced parethesis. Happened to me every time unless attention was paid, because it works not a like what your finger-memory expects from new line entering. Do you experience this? Does autopairing.vim solve this issue?

> without my explicit command

Technically, the "explicit command" requirement is fulfilled because you explicitly installed the plugin.

I learned vim by trying to learn Ruby/Rails(my first experience with programming). It got tedious to open files by looking them up in the Mac Os Finder. Then one day, someone showed me how to tell an application to open a file via the command line. I'm a noob. Vim found its way into my workflow, and I haven't looked back.

If you need 4 weeks to learn a text editor, this might not shine the best light on your editor’s ui.

Making your mouse a dust collector is key.

I use qutebrowser for internet

Ranger.py for file manager

I also use a tiled window manager (i3)

The only time I use the mouse is when I am doing creative work (video editing, graphics or music production)

I use VIM bindings in R Studio and VS Code and I am actually using less of VIM and more of VS Code strangely.

For me it was just a week until I was as good as I had been in sublime; all uphill from there. Now I have to use all the time I save to mop people's drool off the floor behind me.

The only real way of learning vim is starting with nvi (the real BSD Unix vi) for basic editing before going anywhere near vim.

That would be learning vi now, wouldn't it?

....why? Nearly every server has real, honest to goodness ViM installed on it these days, and nvi is extremely limited in its capabilities by comparison.

I'd add the recommendation to disable arrow keys in .vimrc

It forces you to learn hjkl, and thus helps keep your hands on the home row.

I love this vim comeback.

Honest question: why?

https://stackoverflow.com/questions/597077/what-are-the-bene...

Why should I learn VIM? I still don't get it, a sudden waterfall of articles about VIM>

IMHO.

You need to know the basic vim commands in the case you are stranded in a remote server and need to modify a file. It is also handy to do quick changes to a file when you are in the command line.

I used to do software development in vim back in the day, but I don't do that anymore. Now days I use sublime for scripts and an IDE for larger projects.

My recommendation. Commit the basic commands to muscle memory but you don't need to be a power user.

Ok, so it's not that the dev community is moving from VS Code, Sublime to VIM, uff...

In case I'm stuck I used to use nano. but like you say might be worth learning vim vasic commands.

Honestly?

You shouldn't learn vim. You should learn a text editor, and get really, really, REALLY proficient with it. As programmers, one of the core skills of our job is to be able to manipulate text efficiently. After all, productivity is knowledge + tools + focus, right? All the knowledge and focus in the world doesn't help you when you're not able to efficiently do the mechanical part of your job.

I chose vim because it's what I first learned in college. You might end up choosing Sublime, or Emacs, or even Atom. It doesn't actually matter all that much what you choose, so long as you hone the use of your text editor to the point where you can manipulate text without thinking about the mechanics of it.

I like vim because it's built specifically for navigating through files quickly without any mental disconnect: moving through a file doesn't require me to think through the actual actions I want to take-I just think, and muscle memory allows me to do what I want. I like vim because it's consistent, the same keybindings always work everywhere in the same way. And I like vim because I really believe in the composable model used by its motions and actions; I feel like it allows me to very concisely express what I'm trying to do without me having to think about it.

I also love vim because it automates parts of text editing that I find annoying: I'm a very heavy user of macros and custom functions because I have a lot of tasks that I repeat constantly and I've automated all of them.

Can your text editor do all of that? Well, the answer is probably. But you should learn the deep intricacies of whatever editor you're using, just like a pianist might understand the exact sound profile of their instrument, or a chef knows the weight and sharpness of all their knives. It's our most important tool, and honing it to the sharpest edge we can is essential to becoming better.

But that's just my (very philosophical and hand-wavey) opinion.

Reply on news.ycombinator.com