Maybe you can cover macros since they are conceptually very simple and very powerful.
They may seem a bit complex but are quite simple. Basically you just record your editing movements and play it back.
How macros work: press q x to record and q to end. Then repeat with @ x, where x is the name of the macro you want to use (you can have several macros). Anything you do will be played back. That's it... Conceptually simple.
A nice trick is to record a macro for a single line and place the cursor on the start of the next line at the end of the recording. This way it's possible to operate upon large blocks of text in a similar way by just repeating the macro. The key then is to use generic movements like "go to the beginning of line" (^), "go to the end of line" ($), "skip word" (w), etc.
As a silly toy example, if you have a list of strings in a text file, you can turn it into a list of quotes with (from the top of my head):
qx<Home>i"<Esc>$i<Right>",<Down><Home><Esc>q
(Record macro, go to beginning of line, insert mode, write a quote, exit insert mode, go to end of line, insert mode, move right, write a quote and a comma, move down to next line, move to the beginning of line, exit insert mode, end macro recording)
Then to process 100 lines, you'd do:
100@x
That turns these:
alpha
bravo
charlie
delta
...
into
"alpha",
"bravo",
"charlie",
"delta",
...
If you have hundreds of lines of that you'll start to appreciate the easy automation.
I use macros to do drive-by mass-edits without resorting to sed, scripting, regular expressions etc. since the cognitive load of those is higher for me.
My favorite newish-to-me macro trick is to use "recursive macros" -- macros that call themselves at the end, eg `qa[do something]@aq`. The idea (at least for me so far) is to record a line-wise action that goes to the next line before calling itself and will fail on the first non-matching line. For example, if you need to put some text after the first `0`, using commands like `t` or `f` to get there will fail if there is no `0`, but `/` will go to the next `0` on any line.
A macro like this will just keep calling itself until it fails, which is nice for files with thousands of lines and you want to make a change that is not conducive to a regex.
As a tip that took me a while to figure out, you can search within a visual selection using `\%V`, which may make it easier to reliably go to a specific part of the current line (compared to t or f like I mention above).
A slight alternative to recursive macros, macros are repeatable actions, so this works: 100@a
I use it so I can run the macro in batches a couple times and check if I made any mistakes, before picking an absurdly high number to hit the whole file.
Likewise - with visual mode it's normally pretty quick to select an area and do a basic regex, even for things like re-indentation (auto-completes to something like :'<,'>s/^/\t/) even though I'm sure there's a 'proper' way to do that
For that example I would open the document in Sublime Text, select all, and split selection into lines so that I have an independent caret on every line. Then I'd just type the quote at the beginning and end of each line - the home/end keys will put each caret at the beginning or end of its respective line.
Multiple cursors has been supported for quite some time now in VSCode, as well as related useful default editor shortcuts like jump cursor by word, beginning/end of line, etc, that are especially useful when moving around multiple cursors/selections simultaneously.
I was going to say that one annoying thing about these macros is you can't press . to repeat the last macro. It is annoying having to count out 143 lines and then do 143@x or what I tend to do is do it in batches of say 20 until I get to the end..
But this has prompted me to look this up and it turns out that you can use @@ to do this. This will make my life a lot easier, I can just smash <Shift 2> until all my lines are updated.
Another notable trick is that vim registers are case-insensitive -- and since macro's are just stored in registers, macro's are case-insenstitive as well. so @q == @Q, which alleviates some of the RSI problems with spamming @q.
Yes, that's only for writing. For example, to collect all lines matching a pattern into a register with
:g/pattern/y A
you need to use an uppercase register ("A" in this case) because it executes `y` once per match. With `y a` instead of `y A`, you would end up having only the last match in the register.
I also use a lot of macros. I just learned that macro registers are the same as regular registers, so you can actually paste the contents of a macro and examine it or save it to a file (e.g. "xp after recording your macro).
I use the . (dot) command a lot out of habit. It executes the last command. If the last command was a macro execution, dot doesn't execute the macro - it executes the last command of the macro. Is there a way to fix this?
edit I see someone else answered this - use @@ instead of .
Another simpler way (even simpler than macros) that works great for simple mass editing is visual blocks. In normal mode, press Ctrl + V and you get to select a literal block of text (not like visual mode, where the text is sequential). Then you can for example, do a "c" to change the selected text in each of the rows that your block covers. This is especially practical to remove a column. Just select the column, press d and voilà.
Macros really shine when you need to do a bit more complex stuff, there is certainly a cutoff between ease of regex "from the top of my head" vs. spending time formulating it.
I’d highly recommend Drew Neil’s Practical Vim[0] for much more like this; it’s broken down into easy chunks and gets into the _why_ as well as the _how_ of Vim’s techniques.
Modern Vim[1], mentioned elsewhere in the comments, covers more advanced Vim usage.
I feel composing commands is where the real power of Vi(m) comes from. This can be really helpful to someone just starting out with Vim.
I got a boost in my Vim productivity after reading a similar StackOverflow answer a couple of years ago. It's a nice read for people familiar with Vim, and another good resource for new users.
I'm not sure I'd call any of this "intermediate" Vim. Most of it appears in vimtutor, and the rest in the "basic editing" portion of the reference manual.
For anybody who's found more IDE-y activities a bit beyond the current generation of VIM plugins (looking at you Typescript), the Vim plugins for VsCode and Visual Studio are actually surprisingly good and I find myself at least as productive as I do in Vim.
I imagine it might be quite a good starting point for somebody who's used to VsCode productivity but wanted to get into vim without going full vim!
The problem I have with those plugins is that I use a lot of split buffers not just for editing but also for exploring directories using :Explore for example. Some IDEs+vim plugins support horizontal splits but then when you have to jump between different modes such as explorer or console they use different shortcuts.
Nevertheless, I think that VIM support for IDEs has improved a lot these past years. VSCode and Jet brains have done an awesome work integrating it to their software.
I've managed to get the classic vim `<C>-w` + h|j|k|l working in VSCode. Sadly my convenient remapping of that doesn't work :(
My annoyances are pretty small: not being able to do `:e ` and then tab complete the directory structure and the fact that VSCode has splits with tabs rather than tabs with splits.
The reason I wrote this is because I've been pair programming quite a bit lately and also mentoring some new vim users—so I wrote this little guide to help vim beginners level up their skills a bit.
What I noticed is that a lot of vim beginners find composing commands and text-objects to be kind of mind blowing.. and even more experienced vim users mentioned that these were the things that made them have that "aha" moment and convinced them to learn more.
Great article! The features you showed were some of the ones I've had my first "Oh, now I get why vim is so great"-moments and that really boost your productivity.
> Tip: Generally after you’ve inserted some text, you want to return to command mode so that you’re ready to enter your next command. I’d recommend pressing esc any time you’ve finished typing.
Totally agree with this. What really helped me with getting this into my muscle memory was remapping Capslock to ESC which seems to be what many (most?) vim users do.
I'm not quite convinced about this as general advice :
> If you’re like me and never learned to touch type properly, just use the arrow keys, it’s fine, don’t worry about it.
When I decided to go all-in on Vim keys some time ago (trying to find plugins for everything), it didn't take long to transition to hjkl. I think it's easier and more convenient to stay near the home row rather than moving my hand over for the arrows. I don't strictly touch type either.
I think the concerns others have mentioned about the title/content level are valid, but even though I knew most of the commands I enjoyed reading this! I quite liked your writing style and page design.
Does it mean both party have to use the same editor? I wouldn't participate in a pair programmnig like that.
Pair programming is best when everyone can use one's favorite editor. When there is a pair switch there is also an editor switch if the other party prefers a different editor.
“If you’re like me and never learned to touch type properly, just use the arrow keys, it’s fine, don’t worry about it.”
Are touch typists rare these days? I feel like people these days forego even learning to type properly. I dont understand why they refuse to just learn it, it is such an essential skill to have.
I think it’s hard for people to make themselves dedicate the time to learn something when they aren’t forced to. A big function of school is to force people to learn things, things they could perfectly well learn on their own if they didn’t lack the willpower.
I’m very grateful that my dad, recognizing back in the 90s how important a skill it was, made me learn to touch type when I was just six years old. I never got as good with the number row as with the letters, which was fine for a long time as I am very quick with the number pad, but nowadays I mostly use my laptop which doesn't have a number pad. It is a silly thing, because I could with a few minutes every day for a couple of weeks train myself to be as quick with the number row as with the letters, but I haven't and probably never will. There is no pressing need for it in my life and no one to force me to do it.
I'm a pretty decent touch-typist, but I have some hiccups when using the symbols on the number bar (@#$%^ etc), or brackets, or other stuff that's common when programming but uncommon in most texts used by touch-typing programs.
So I wrote a little program to download source code from Github and allow you to type along with it, and measure the number of typos. It's super old, half-finished and was one of the projects I used to learn Python, so the code is hot garbage and unmaintained, but it might be an interesting thing to look at and use if anyone wants to practice touch-typing on source code:
I think increasingly so due to the prevalence of touch screen typing (I've no evidence to cite, it's just a gut feel). My kids, aged 10 & 12 cannot touch type, despite plenty of experience on a keyboard, they just spend far more time on phones and tablets.
Personally, I learned to first type in the mid to late 80s on a 286 using Mazis Beacon and an IBM selectric typewriter. I wasn't hunt and peck, but still looked at the keyboard while typing.
I didnt really no-look touch type until a took a typing class in high school where they covered your hands so you couldnt see the keyboard. That was the key to me really improving. I went from around 45 wpm to about 120 wpm. I didnt really get comfortable with the number/symbol row until I started programming heavily. Still had to look down for a while to find those symbols. Also one of the reasons I hate nonstandard keyboard layouts. I know where "{}[]/\" are, but on a laptop or compact keyboard, I'll have to gunt for those potentially.
I (finally) learned to touch type after picking up a Microsoft ergonomic keyboard a couple years back. Really forced me into touch typing since there was a clear division between each hand.
Prior to that, I could type at a very decent speed and pseudo touch typed: I would put my fingers on home row but quickly I would lose that discipline and look at my hands as I typed and use the wrong fingers for various keys. I'm guessing that most people who are using VIM (or just programming on a daily basis) are close enough to count even if it isn't proper touch typing like I had in the past
That being said, I'm SOO much faster than I used to be and would encourage people to grab an ergonomic keyboard. Better for your body and it forces you to type properly :D
We were taught to touch type in grade school, but I goofed off during those lessons. I got through college without needing it. I was a speedy point-and-peck typist, which was good enough for that period of my life.
Later on, when I learned to program, I found that my slow typing speed frequently caused me to lose my train of thought midway through a line of code. It was frustrating enough that I spent a month teaching myself to touch type. Basically, I took online typing tests over and over after work.
Since then, my typing speed has at least doubled. I don't look at the keyboard anymore, and I'm able to get my thoughts down with _much_ less friction. I can't recommend it enough.
Truth, typing quickly is crucial to getting thoughts out of your brain. Our brains think much faster than we type, so typing is our bottleneck. I am only at 60WPM (tops) and it really helps. It especially helps for the large majority of an engineering/programming job, which is not coding, but communicating.
Also helps writing code big time, but the big win is in communication, and as someone else mentioned during pair programming sessions.
You might more than you think. That was the case for me. Rearranging the key caps on my (non-laptop) keyboard quickly cured that, and is an interesting exercise when you can afford it.
Idea for someone looking for something to build, on my list but probably won't prioritize it for many years as I'll build it eventually but would welcome someone else building it. If anyone wants to work on this ping me and maybe I can help collaborate/mentor.
Typing App for Engineers, MVP:
* Load a canvas with a preloaded code snippet, the text is mostly greyed out
* When typing your text shows over the greyed out text, but darker, red if the character doesn't match
* Time how long it takes to type it perfectly
Gold plating:
* Users can login
* Users can upload own code snippets for community contributions
* Leaderboard shows top times and users for those who typed it perfectly, only perfect scores are registered, because code must be perfect or it won't run.
This could also allow an engineer to learn APIs while learning to type. I did this with 60 or so pages of Drupal code a few years ago. I used Compiz fusion's overlay opacity control to put a loaded code snippet into VIM,reduced the opacity of the window slightly, then laid another VIM terminal on top of it, reduced the opacity of that terminal window so I could see behind it and started typing the slightly greyed out text from the window behind.
Been meaning to put this out on my blog but this is a good start.
I was actually learning React around the time I was learning to touch type. So, naturally, my first project was to build a typing test[0] :) Looking back, I cringe at the code quality. But it worked and I had fun doing it. ¯\_(ツ)_/¯
I like the idea of typing out code though! I think there are some sites that do that, like https://typing.io/
SWEET! Typing.io is perfect and almost* exactly what I was intending to build. Can even upload own samples, and it focuses on working code, no typos. I think I'll actually pay for this too!
* It doesn't seem to have the social/competition/gamification aspect built in like Vim Golf.
Ah, sorry it took so long to respond—I was at work. I used KeyHero[1], mostly because the passages were interesting enough to keep me from getting _too_ bored.
I studied a few charts beforehand, but the repetition is really what made it sink in.
I used Tipp10 about 12 years ago when I forced myself to learn it. What worked for me is to do the basic lessons and then always use touch typing without looking whenever on a keyboard. You’ll be slower initially, but speed will increase over time.
I learned on https://www.typing.com/ (typingweb.com when I did it). One thing it doesn't do well is special characters and numbers though. We need a typing course for coders.
e.g. How fast can we type the below accurately?
function typing_test($foo = 'bar') {
return $foo
}
I learned touch typing when I was 25. THis was probably after 6 years of programming and computer use. I could already type fast enough without looking at the keyboard, but I decided to learn anyway.YMMV, but it took me about 2hours for 5 days to get comfortable with touch typing. For programmers who are still wondering the effort required, just do it!
For me the biggest advantage I see after learning touch typing is lesser errors because you are getting proper feedback from the screen while you are typing.
I taught myself at age 30 using online software. However, yes, touch typists in this industry seem rare to me. I often get called out on conferences for my typing, which is at best only about 60 words per minute. Maybe it is because I don't mute as much as I should, OR is there another reason?
I’ve noticed with a few colleagues when pairing that they were rather slow at typing and made plenty of mistakes. Then I realized that they were not touch typing and always had to look down for the backspace key.
I was quite surprised to see that there are programmers that don’t do touch typing.
I believe one learns such skill implicitly while typing lots of texts/prose continuously, which is not needed for programming, especially nowadays, where the editor properly guesses the needed token after you type 1 or 2 symbols.
I think this is pretty basic in terms of general vim commands. Navigation and insertion are all basic use cases that beginners should know. That said, the section about composing commands was really interesting!
On an Ubuntu box install the nvi-doc package, in /usr/share/doc there'll be two documents vi.beginner and vi.advanced. Open the latter with vim and it'll teach you the more advanced commands.
One thing I miss on Vim I have on Spacemacs with the Evil layer is the "a" object (for "argument"). With it I can delete/change an argument of a function in a flash.
Example (cursor on the last arg):
importAntigravity(usePython, crashTheUniverse)
<type daa for "delete an arg">
importAntigravity(usePython)
As an emacs refugee, I disagree. I tried everything to get rid of the lag and it just became unbearable after having significant exposure to vim through pair programming. Now I just use Vim instead of trying to get Emacs to work like Vim.
A well written guide for introducing some of the power of Vim to a new user.
One thing I'd suggest for the author, based on a quote from the article - "Invest your time to learn new skills" - Try and invest some time to learn touch typing.
I worked as a developer for years thinking that it wasn't worth the effort, but after taking a couple of weeks to learn, I never looked back. My productivity, particularly with Vim has jumped leaps and bounds.
You may like to also try `CTRL+[`. It's the telnet escape character and seems to be a general substitute for ESC on OSX, Windows, and I think Linux too. I find it pretty quick since my hands can work together.
Another handy tip I ran across was to remap CAPS LOCK to CTRL. Quite nice for both Vim and Emacs users once you get used to it.
Alt+Movement is what I usually use, since it's easy to hit on my keyboard, and lets you combine dropping out of insert mode and a movement command to move you towards where you want to be for whatever you want to do next.
If you don't want to move, you can just hit Alt+l as the "default" escape.
Beginner vim is being able to exit vim successfully, knowing how to hit i to insert text, and how to save your file. Just because you are familiar with it doesn't mean it isn't intermediate, it just means you are already intermediate.
As a Vim user one of my gripes when first using Vim was how cumbersome the built in help files were. I guess that's why there are so many "vim cheatsheets" out there, the built in documentation is a pain to use.
My collegues are constantly complaining their (mac) laptop keyboards are terrible, however aren't ballsy enough to say "F-U" to the corporate choice of a mac or a windows laptop.
Well, HNers complains the MacBook keyboard as it’s a complete trash, but please remember that there are plenty of people that likes and even loves the butterfly keyboard. The keyboard itself is pretty awesome and provides much stabler keys than usual keyboards (whether it’s membrane or mechanical). They work regardless of what part of key I press, which means that typo rates significantly decreases. I’m happily using my MBP’s butterfly keyboard with Vim. Just please, don’t say keyboards are terrible after using for a few hours. There’s a reason why Apple is keep placing the butterfly keyboards in top-range Macbooks.
I added this very handy little mapping a while back:
noremap! kj <esc>
it means when you press kj [0] that it's the same as pressing escape.. very handy (the times when I deliberately want to press k and then j are still zero)
Mapping Capslock simultaneously to both ESC and Control solved this problem for me. It might not be your piece of cake but it definitely improved my vim experience greatly. See for example (I'm not the author) https://www.dannyguo.com/blog/remap-caps-lock-to-escape-and-...
One thing I always wished VIM had was the generalized ability to repeat the last navigation command with "," and ";". I mean if I use "[m" to go to the previous method, then I want to be able to repeat that with ",". Never understood why ",' and ";" are only for "f" and "F"
The balloon comparison is strange. I would've just said that adding shift to a shortcut often reverses it... / for search and ? for search backwards, alt-tab to switch windows, alt-shift-tab to go the other way, ctrl-tab to go to next tab in Firefox, ctrl-shift-tab for backwards. It's incredibly common.
Just to extend this - if you're often using different users (or need to otherwise deploy via a configuration manager), I've found out that a good way of having system-wide options on Debian is /etc/vim/vimrc.local with something like:
" Workaround stupid defaults.vim behaviour
if filereadable("/usr/share/vim/vim80/defaults.vim")
source /usr/share/vim/vim80/defaults.vim
endif
let g:skip_defaults_vim = 1
" Disable stupid seeking to last position
autocmd! vimStartup BufRead
" Disable stupid mouse support
set mouse=
I learned a new one recently. zt redraw so that current line is at top, zb redraw so that current line is at bottom, zz redraw so that current line is at the center.
If you are on twitter, you might want to follow MasteringVim. You'll learn one trick every day.
This is less than beginner Vim, certainly less than vimtutor, and far less than any other Vim tutorial I've seen. This makes the title feel like clickbait.
What about "Towards Vim Fluency"? Just as click-baity, but maybe a bit more precise ;-)
BTW, even though I've used vim for a long time and consider myself fairly advanced, I had somehow forgotten about "I". You've saved me countless "^i" invocations... Wait... That's cording! It's cheating :-) (But it's OK because I'm a closet Emacs fan)
Cityhometution is an online portal to find the professional tutors and tutor jobs which give the special and wide opportunity to the students/learners to select the best Home/online Tutor by their own choice under one roof with our unique features.
We are in the field of connecting Qualified Home/Online Tutors since 2005 with an extensive experience in dealing students and tutors in a familiar way.
• Trustworthy Home Tuition Providers
• All Major Cities Of India
• Over 12 Years Of Impeccable Service
• Qualified And Verified Home / Online Tutors
• Provided Tutors to Thousands Of Students Since 2005
• Our Students Are From Prestigious Corporate Schools and Colleges
• Having more than 1,00,000 tutors in around In India
• International Experience Trainer in Corporate Teaching
The most notable tool to help improving your skill in vim (after doing the excellent vimtutor), is to go and do some vim golf. You can see the solution from just one point better than you, improving your skill gradually.
They may seem a bit complex but are quite simple. Basically you just record your editing movements and play it back.
How macros work: press q x to record and q to end. Then repeat with @ x, where x is the name of the macro you want to use (you can have several macros). Anything you do will be played back. That's it... Conceptually simple.
A nice trick is to record a macro for a single line and place the cursor on the start of the next line at the end of the recording. This way it's possible to operate upon large blocks of text in a similar way by just repeating the macro. The key then is to use generic movements like "go to the beginning of line" (^), "go to the end of line" ($), "skip word" (w), etc.
As a silly toy example, if you have a list of strings in a text file, you can turn it into a list of quotes with (from the top of my head):
(Record macro, go to beginning of line, insert mode, write a quote, exit insert mode, go to end of line, insert mode, move right, write a quote and a comma, move down to next line, move to the beginning of line, exit insert mode, end macro recording)Then to process 100 lines, you'd do:
100@x
That turns these:
into If you have hundreds of lines of that you'll start to appreciate the easy automation.I use macros to do drive-by mass-edits without resorting to sed, scripting, regular expressions etc. since the cognitive load of those is higher for me.
Edit: formatting