I wish there was something like nano + plugins. If I had that I could implement most of what I need (other then auto-completion for a crap load of languages).
I second the suggestion of using vimtutor to get started (uninstalling other editors helps too!).
i was just one of the ones stupid enough to waste two weeks of productivity to learn a new tool lol
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
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."
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
git checkout $(lw 5kyiW)
http://www.catonmat.net/blog/bash-vi-editing-mode-cheat-shee...
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.
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.
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.
I still use editors like atom for web development where I go through frequent iteration cycles and make heavy use of the clipboard.
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.
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.
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.
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.
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.pngCan 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?
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.
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.
Because yes, Vim ultimately will be faster.
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.