Learning Vim is probably a bit like learning to bicycle/swim. It requires a lot of conscious effort at first but eventually becomes a second nature. Also, I doubt many vim users would use "nano + plugins" if vim suddenly disappeared. The fact that vim has many plugins and runs in the terminal is nice but isn't the main reason people use it IMO.

I second the suggestion of using vimtutor to get started (uninstalling other editors helps too!).

There's something to that, yes, that a lot of things become second-nature (e.g. once you learn Vim, when you're in Nano on an unfamiliar machine, you start finding yourself accidentally typing Esc-:w to try to save a file).

There's also something about "this is totally unfamiliar and not at all incremental upon what I know." I was vigorously against vim after trying to do it many times, eventually I found out a base set that allowed me to learn incrementally, now it's not so bad. The big thing is to totally forget all of these people who are saying "vim is like an awesome language for text editing." Maybe it is, but that's an awful sales pitch. This person wants to spend a few minutes editing source code, not spend a year learning a new language.

The minimal starter set for Vim is something like:

    # From Command Mode #
    dd     | deletes a line
    .      | repeat whatever you just did, for example pressing I, 
             then the delete key 4 times, then Esc is one command
             which dedents a space-indented line by 4; now you
             can go down a block hitting . at each line to 
             dedent it.
    i      | switch to edit mode at present cursor
    I      | edit at beginning of line.
    A      | edit at end of line.
    u      | undo
    Ctrl-r | redo
    

From there probably the next thing I would teach people is brace jumping with %, regex-jumping with /, visual-lines mode shift-V and either cutting with d or copying with y, then pasting with shift-P. Finally macros with qp ... q ... @p. After that, maybe dealing with multiple buffers. Just let people use the arrow keys to navigate, don't get too religious about the home row or letter repetitions like d5d.

I think that's a basic skillset that will let you say "okay, my thesis advisor is making me put two spaces after each period that's not an abbreviation in this document, what editor should I use for that? Well I want to step through everything just to make sure, but let's just use Vim where I know I can write "fix this one and then jump to the next period" as a macro, and interleave that with some basic navigation when it's not right."

the problem with learning vim is that it's like learning to bike by biking to work. most people use vim when they code, and they code at work, so using vim is directly in the way of getting any productive work done.

i was just one of the ones stupid enough to waste two weeks of productivity to learn a new tool lol

I managed to stack learning vim with normal on-boarding related slack by picking it up on my first day at my first coding job. IMO, one of the top ten decisions I've made in my life.

Same, using vim "full time" was what really made me learn and appreciate it. Before that it was just something I would occasionally use when making quick edits on a server.

Vim is very easy, I think it's just simple to get overwhelmed with it.

There are a couple of tools which gamify Vim. I personally haven't used them. But some say they're pretty good.

For me, what worked was just jumping in and going whole hog. I tried disabling the arrow keys in Normal Mode, so I would have to use hjkl for navigation. But my keyboard puts the arrow keys in easy reach (Kinesis Advantage), so it turned out not to be much of a need.

What you may like is turning on relative line numbers. That way you can visually see what line you're at, and how many lines away your target is that want to jump to. Then you can practice going 5k to go up five lines, or d2j, to from where you are to two lines down.

This article was actually eye-opening for me: https://yanpritzker.com/learn-to-speak-vim-verbs-nouns-and-m...

Maybe it'll help you too.

:wq

I wrote a shell toy to help me learn vim motions.. the idea is you can grab parts of the output of previous shell commands by passing vim motions. So like when you want to say "git checkout <that branch mentioned 5 lines up in the previous command's output>" you can do it :)

  git checkout $(lw 5kyiW)

It's more of a toy than a power tool but I do use it somewhat regularly.

https://github.com/bgribble/lw

For bash or any other application using the readline library you can configure it for vi mode by adding 'set editing-mode vi' to your ~/.inputrc. Note for bash you can instead add 'set -o vi' to ~/.bashrc to avoid setting the mode for all readline applications

Interesting, you may be interested in vi mode in bash.

http://www.catonmat.net/blog/bash-vi-editing-mode-cheat-shee...

Why do people not like :x ?

:wq is a natural extension of :w, and half the time I haven't even decided to quit Vim until I've already typed the :w.

It's an extra thing to remember. When I'm coding I usually just do :w, so when I'm editing config files I do :wq because it's the same thing (write the file) plus a new action (quit) in my head, instead of a totally different action (save and quit)

There's also ZZ which I find easiest of all.

Vim takes a while to grok. You have to move away from the mindset of "memorize a lot of strange commands" to the mindset of a language for text manipulation. Then, learn the absolute minimum set of commands ([a]ppend, [i]nsert, [d]elete, [p]aste), start using, and add vocabulary gradually. Just like learning a new language.

As others have said, start with the basics and learn to use the help system. I found it enormously helpful to watch videos like Derek Wyatt's[1] that show a Vim master at work and explain the basics. It's not that I learned the key mappings from watching videos, but I did learn the potential of Vim.

Then, with a basic understanding of how to use Vim as a beginner and a comprehension of the possibilities, I paid attention to how I worked and looked for areas for improvement. When I spotted something that I could do more efficiently, usually reducing repetition, I used the Vim help and Google to find out how to do it.

A trivial example would be using the hjkl movements to go further than a couple of characters. First, I learned to move in words (w and b), then I learned to use the f and t searches and incremental searches. Then using counts to move specific numbers in whichever direction. After a month I stopped reaching for the mouse or doing llllllllllllllll to move through text.

I learned slowly: maybe adding one cool key mapping or feature to my workflow every couple of weeks. After a few months, it adds up. Soon you don't even think about it. You see what you need to do and your fingers do it for you.

Vim is a complex beast: an accretion of decades of features, most of which you'll never need. The best way to learn is by the same process of accretion. You'll start off using Vim like a non-modal editor, but if you stick with it, your patience will pay off.

[1]: https://vimeo.com/user1690209/videos

In emacs, at least, every command has a name. Anything you'd like to do can be searched using tab completion and a little guesswork, at first, by typing `alt-x` followed by the first couple letters of a plausible name for the thing you are trying to do.

It's an extremely clumsy but totally workable way to get around if you only rarely need to edit a text file on a remote server. For example, if you highlight a section of text, you can `alt-x comment-region` and emacs will automatically insert comment markers at the beginning of each line (`uncomment-region` to undo the process). Or `alt-x save-buffer` to save.

The myriad keyboard shortcuts are just aliases for the named commands, so it's a straightforward transition from the clumsy tab-complete workflow to a more efficient one once you know your way around.

After a few months using Spacemacs, I moved to neovim, but took the idea of the space leader and "meaningful" mappings with me.

I remapped the leader key to space, and created a bunch of sensible mappings: all my Markdown mappings are under <space>m and so on.

I left most of the normal mode movements at their defaults, though.

It would be cool if someone could do a Spacevim vimrc or plugin.

someone started a spaceneovim: https://github.com/Tehnix/spaceneovim https://www.reddit.com/r/neovim/comments/539oxk/spaceneovim/

Nice! I'll give it a spin.

I''m curious, why did you move away from Spacemacs?

It's heavier than Vim and a fair bit of Emacsy stuff leaks through. It's a great project, but I prefer Vims way of doing things. Also I have a bunch of custom Vim functions for doing stuff like invoice generation and I didn't want to reimplement them in Lisp.

Just curious, what editor(s) do you use? I was using Sublime Text, and for the hardest part of switching to Vim was feeling the huge productivity drop in the beginning as I relearned how to do everything.

I weaned myself off other editors by using vim for thought-intensive programming. When most of your time is spent trying to come up with efficient solutions to your problems, spending a little time learning more about vim isn't so bad... and can be a welcome distraction.

I still use editors like atom for web development where I go through frequent iteration cycles and make heavy use of the clipboard.

I used sublime for a bit, but I didn't like getting nagged. Right now I'm using some JetBrains products and Nano.

I sketch everything out into nano, then I pull it into CLion when it's ready to be cleaned, updated, iterated, and in general changed to become a "final" version.

The trick is to pay for it.

JetBrains products aren't free either...

I use Sublime (happily staying here as well) but I use vim still for tiny editing very now and then. I'd recommend learning just moving around (I use arrow keys). A for append to end of line, I for insert in beginning, dd for delete line, i for insert mode, wq for save and exit. Maybe 5up/5down etc for faster navigation.

This is pretty much what I only use. I feel quite comfortable with vim and if I ever feel like I want to learn more, knowing how to do these super basic steps feels like a solid ground.

If it helps, I learned vim by following the most basic tutorial at first (vimtutor), learning how to navigate, save my changes, switch between command and insert mode, and not much more. I then forced myself to use it.

vim's defaults are, honestly, terrible. So you'll quickly run into lots of little frustrations. For each one, I'd look up potential solutions online, and if I could find a solution which was intelligible to me given my level of understanding of vim at the time, I'd use it.

Eventually, some of those solutions involved using plugins.

After a few months, I found myself culling plugins that I'd installed as I learned better solutions that either weren't intelligible to me earlier or were just too overwhelming. For instance, NERDTree is an early plugin I used, but I eventually reached a point where I never touched it, so I removed it.

Try out Vim Adventures to get some basic commands down. Then find Vim emulation for your editor of choice. Leave it in insert mode as much as you need at first. Slowly you'll start using more Vim commands. In a while you'll wonder how you ever edited without it.

I second the recommendation for Vim Adventures. The free part is fun, and being forced to work with a subset of features as you acquire more gives you a better feel for when they're appropriate.

I assume the non-free bits continue in suit, although sticker shock prevented my finding out. For someone benefiting beyond entertainment, it's likely worth it. As a long time vim user I had trouble justifying it.

I started out like this. In effect in the beginning you can do everything in edit mode, you don't actually need the key bindings. Pretty much the only thing I learnt was 'dd' to delete a line (which actually just cuts the line).

The other very simple thing is just typing '/' and then searching. It's much simpler and more natural once you're used to it than Ctrl+F. Then further searching is just hitting '/' again instead of F3. Firefox has the same command that you can use, just hit '/' and you can start searching.

Underlying this though, is a very useful and powerful editor that's there and waiting for you to use if you want to invest the time.

I come from a Windows world so wrote up a table of comparable commands [1].

Edit: It is also pretty cool however, that if you install Vim on Windows (it gets installed as part of Git) and with a bit of Solarized colours [2] you can get a IDE level editor in your DOS prompt [3]. It blew my mind anyway.

  [1]: https://ianchanning.wordpress.com/2012/04/07/vi-commands-for-the-windows-user/
  [2]: https://github.com/neilpa/cmd-colors-solarized/
  [3]: https://dl.dropboxusercontent.com/u/7765571/images/screenshots/2016-10-17%2020_32_05-Make%20me%20a%20sandwich%20-%20vim%20%20DNA.hs.png

> beginning you can do everything in edit mode

Can I make an alias for vim or emacs to keep me in edit mode at all times? That's one of the worst things about the editor.

The other "Worst" thing in the editor for me is that it doesn't show the common shortcuts at the bottom like nano does.

Is there a way to do this? Is there a plugin that observes all of the shortcuts you use and lists the most common ones at the bottom?

Probably what you're looking for is gVim-easy which is installed along with gVim. It starts in inset mode and the menus give you some idea of the shortcuts available. gVim should also respond to OS shortcuts like C-c, C-v, etc.

http://supportweb.cs.bham.ac.uk/documentation/tutorials/docs...

Personally I would just run vimtutor in the terminal, watch vimcasts.org and then read the PragProg book.

> it just doesn't make sense to me.

Here's how to think of Vim that will make sense.

Suppose you have two identical codebases that each need to have the same 200 lines changed. Functions need to be added, comments to be removed, templates need modifying, and so forth. In one of the two codebases, you use Nano to apply those changes. In the second codebase, you use Vim. Assuming the Vim user was proficient at Vim, you can be sure that he/she used 1/3 -> 1/2 as much hand and wrist effort than the nano user to make the same changes. It could be that the effective Vim user ended up using less than 1/2 the hand effort than the nano user.

If you extrapolate this over these two coder's careers, you realize that the Vim user is going to be glad he spent the time learning Vim.

Learning how to use Vim has been so rewarding for me. I love coding in Vim and I love learning new ways of doing things.

> Suppose you have two identical codebases that each need to have the same 200 lines changed. Functions need to be added, comments to be removed, templates need modifying, and so forth. In one of the two codebases, you use Nano to apply those changes. In the second codebase, you use Vim. Assuming the Vim user was proficient at Vim, you can be sure that he/she used 1/3 -> 1/2 as much hand and wrist effort than the nano user to make the same changes. It could be that the effective Vim user ended up using less than 1/2 the hand effort than the nano user. > If you extrapolate this over these two coder's careers, you realize that the Vim user is going to be glad he spent the time learning Vim.

This I completely understand, and if I was a professional programmer who had to deal with those sorts of operations regularly I'd probably find Vim very rewarding to learn.

The perspective I come from is that of a sysadmin. If I'm editing large amounts of text I'm probably on a system where I control what's installed and thus can have whatever editors and IDEs I want, within reason. The situations where I find myself forced to use Vim are stripped down appliances where more often than not I'm looking to make a single change in a single line of text.

For that use case basically any editor with a working find feature is equally fast, so I'd much rather have one that uses a standard or at least discoverable user interface.

To me Vim is like one of those simultaneous torquing machines used in modern vehicle assembly plants, where I'm just looking for a torque wrench to check my lug nuts.

I hear you for nano, but what about compared to [graphical mouse-clicky editor of choice] (in non-vim mode)? I know enough of the basic vim commands that I could edit a file if I ever needed to but how much hand effort could it save me vs. kate or VS Code? (though i really prefer notepad++ to both of those) I feel relatively efficient in a good graphical editor but maybe I just don't know any better? Really just give me reasonable multi-selection features and I'm happy.

To prove that Vim is faster than a graphical editor as well, I might make a WebM where I edit two identical files, one with notepad++ and one with Vim. Would you appreciate that? I will do that if you respond to this.

Because yes, Vim ultimately will be faster.

There's a plugin (can't remember the name of it right now) that lets you use mouse controls as well. Click where you want the cursor, scroll, click on which tab you want, etc. That was game over with Sublime for me.

I don't think you need a plugin for that? set mouse=a, unless I am missing something

Yep you're right, my bad.

I would suggest you try out vim with a scratch document and reference book. Focus on figuring vim out that way. It helped me.

I spent the last 2 hours of every work day using VIM, regardless of how much longer it took to work on things. By the end of the week, I could jump into vim after lunch. When I started using ':x' in TextMate I knew it was time to leave.

Upon seeing the headline I was hoping this was a reworked version of Vim that was more intuitive, that didn't require the user to learn all the secret handshakes and voodoo recitations to get things done.

I haven't tried it yet, but you reminded me that Slap exists: https://github.com/slap-editor/slap