I might be wrong, but I think you can also do :52 to go to line 52.
I love using this command. It is also possible to copy or move by expanding the command. Using :52co12 will copy line 52 to below 12. Using :52co. will copy below the current line. It even works with ranges :52,55mo. will move 52 through 55 to the current line.
" Jump to first character or column
noremap <silent> H :call FirstCharOrFirstCol()<cr>
function! FirstCharOrFirstCol()
let current_col = virtcol('.')
normal ^
let first_char = virtcol('.')
if current_col <= first_char
normal 0
endif
endfunction
(I realise you were talking about nnoremap L $ and not nnoremap H 0, but I think the two ideas are related and I thought this might useful to somebody out there).
normal means that Vim will use the currently mapped key, rather than the default one. So if you nnoremap 0 .... then your mapping may break since normal 0 will run that mapping. Use normal! to always ignore user mappings. You should almost always use normal! unless you have a specific reason not to.
You can create a script-local function with fun s:FirstCharOrFirstCol() and then refer to it with nnoremap H <SID>FirstCharOrFirstCol(). I personally much prefer this as it doesn’t pollute the global namespace so much with what is essentially useless stuff.
Not sure this is really “intermediate” as it still seems beginnerish, but still important things for any Vim user to get used to. I think intermediate Vim would be more about how to improve usage of makeprg, quickfix, jumplist, netrw, etc.
Once I had that, I was far more likely to define useful mappings, which made editing text easier, which allowed me to think at a higher level, which made me more likely to think of useful mappings… this was actually life-changing, and a principle I’ve tried to replicate with every other tool I use.
For the impatient:
nnoremap <leader>ev :vsplit $MYVIMRC<cr> " Edit my Vimrc
nnoremap <leader>sv :source $MYVIMRC<cr> " Source my Vimrc
If this is “intermediate”, then there are at least 20 experts levels on top.
I don’t think it makes sense to look at lists of things you could do with vim. Instead observe yourself and look for one pattern you do often. Then research an optimization for that. Rinse. Repeat. Do it one by one. Vim is around for decades and it will still be there for you in a few years.
I believe learning vim is a daunting task and tutorial resources which show off the power in a nice and friendly way can be a very good introduction to the subject. I see your point about observing and researching optimizations, but at first sight “modal”, “command mode” and even “:wq” might be too much for someone just trying to get their feet wet.
I’ve been pair programming a lot 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 folks who were new to vim found both text-objects and composing commands to be pretty mind blowing—so yep, this guide only barely scratches the surface but I just wanted to give newbies a taste for what makes vim so powerful.
I don’t think it make sense to dismiss alternative presentations of information that don’t help you learn as unhelpful for everyone else. I’ve been using vim for just over a decade now, full time, and learned a couple of new tricks just by glancing over this article.
I’m in the same position as you are. Have been using vim for a few years and I still learned something new which I can integrate in my editing workflow.
I’ve been using vim for like 10 years and I don’t think I’ve ever used I, I use A constantly, but I always use 0 to go to the front of a line.
Never occurred to me to look for something because it feels find. I learned a lot by thinking “there should be a better way” and then finding it, looking at these kinds of articles every once in a while is useful for finding unknown unknowns.
One day I sat down and actually read through :help in order to get the ideas behind most of the commands.
This article sums up most of what I need to get around quickly, but for more advanced stuff Vi[m] never felt intuitive enough for me and certain tasks were simply too complicated to carry out despite being so simple.
Then there was vis.
It combines most of Vim with Plan 9’s structural regular expressions, concepts such as multiple cursors and more.
Suppose you have a large text and want to edit all occurences of a word as you go: with Vim you’d either record a macro and repeatedly apply it, or (repeatedly) ran some regex substitution (over a range of text) - until you get it right.
With vis, selecting all occurences of “foo” is one :x/foo/ away, leaving you with N visual selections. Pressing escape brings you to N cursors, ready to edit them as if they were one.
This is easily expandable and aids my natural way of thinking immensely.
Want to sort text? Select it with v and pipe it through sort(1) with :|sort.
Want to include a file or some commands input? :< cat file.
Want to pipe text to some command (without reading its output back)? :> cmd.
This is intuitive to me. Easily leveraging external commands is a huge win.
No built in stuff that can be done with regular shell, no VimL, no legacy support (vim), no built in terminal emulator (neovim), scripting support through Lua.
Note that I’m not trying to sell you something here; whatever works for you is good.
It should rather outline what problems I had with Vim and how vis leverages them with a clean design.
Editing code gets fast when you don’t have to think about how to carry out your complex/efficient operation successfully - reuse tools in your $PATH and/or break things down to smaller operations while still keeping focus (read: cursors) where needed.
As a programmer, you spend a lot of time editing and navigating code.
In my experience, not as much as all editor-focused write-ups want you to think. Presumably, you spend much more time thinking what is it that you actually want to do. (Disclosure: my perception is informed by me spending most of the time in Python, as opposed to more text- and repetition-heavy languages like Java.)
Is it? I’m trying to find breakdowns of how programmers spend their time and it’s tricky. I’d suspect it would be something like half our technical time is spent debugging.
I second this. Also for more verbose languages like Java there are usually very good supporting tools, and You usually don’t use a simple editor, but a semantically aware IDE for the task.
I don’t get why people have this need for optimising their text editing so much.
They spend so much time trying to learn all these handy keyboard shortcuts and tricks,
that the actual time they save when editing text is meaningless.
For me it’s absolutely nothing to do with saving time and everything to do with comfort. It didn’t take long to get over the initial hurdle of just running vimtutor and learning the basic keys to move around and edit. From there it was just editing and occasionally thinking ‘I do this [thing] a lot, is there a way to optimise it? Same for my shell setup. It’s not really a deliberate decision to spend ages customising everything, it’s a gradual process that occurs naturally over years out of curiosity, and it pays off.
Edit: the immediate benefit post-vimtutor was being able to keep my hands off the mouse, and that was enough to make it more comfortable than what I had been doing before. I don’t think I would have bothered if it had been that stressful and time consuming just to get started.
Nice write up. I actually didn’t know about
A, so I’ll be using that today. I usually do$ior$ato insert at the end of a line.I might be wrong, but I think you can also do
:52to go to line 52.And also
52G(
ggis avim-ism, so if you’re just using plain oldviyou need to use<number>Gor:<number>)I love using this command. It is also possible to copy or move by expanding the command. Using
:52co12will copy line 52 to below 12. Using:52co.will copy below the current line. It even works with ranges:52,55mo.will move 52 through 55 to the current line.53,55norm! A;will at a semicolon to the end of every line in that rangeThank you!
Yep, I actually prefer the :52 style but I didn’t want to get into explaining : commands for beginners for this article. ;-)
I usually avoid ‘$’ because I’m less accurate typing it haha!
I have a very small keyboard so R, $, and 4 are the same key, but with different modifiers.
is it a Planck?
Yup!
I’ve been using one for more than a year now. I like it so much, specially that, by default, the escape key replaces caps lock, it’s perfect for vim.
Cool kids do
nnoremap L $.That’s a good idea. Unfortunately, I work in two separate vim-emulating editors which don’t support these gizmos.
I actually use L M and H quite a bit, especially when I need to look at neighbouring code. I don’t use the split feature very often, though, do you?
Even cooler kids do:
Explanation.
(I realise you were talking about
nnoremap L $and notnnoremap H 0, but I think the two ideas are related and I thought this might useful to somebody out there).That can be a lot shorter with expression mappings. This is what I map (to Home):
Expression mappings are really useful!
Some other notes:
normalmeans that Vim will use the currently mapped key, rather than the default one. So if younnoremap 0 ....then your mapping may break sincenormal 0will run that mapping. Usenormal!to always ignore user mappings. You should almost always usenormal!unless you have a specific reason not to.You can create a script-local function with
fun s:FirstCharOrFirstCol()and then refer to it withnnoremap H <SID>FirstCharOrFirstCol(). I personally much prefer this as it doesn’t pollute the global namespace so much with what is essentially useless stuff.Intermediate vim stuff I regularly use:
Yeah, these are all great!
Another thing I really wanted to cover but didn’t quite get to was using . to repeat commands.
Not sure this is really “intermediate” as it still seems beginnerish, but still important things for any Vim user to get used to. I think intermediate Vim would be more about how to improve usage of makeprg, quickfix, jumplist, netrw, etc.
I have been using vim for a while, and have no idea about the things in your list. I guess I have some reading to do
I have to agree. I’d consider these bare minimum, without knowing which I don’t know how or why you’d be using vim. I’d forgotten about quickfix!
As an Emacs user, I spent most of my time configuring Emacs
As long as you did it in Emacs, and not vim this is ok.
I never use the (i)n, (a)round, (f)orward, or (t)o commands. It seems like there is always something to learn with vim.
I learned that vim understands tags. That was pretty cool. Still have to try it.
The best piece of Vim advice I ever got was by Steve Losh: define aliases to make it trivial to open and reload your vimrc.
Once I had that, I was far more likely to define useful mappings, which made editing text easier, which allowed me to think at a higher level, which made me more likely to think of useful mappings… this was actually life-changing, and a principle I’ve tried to replicate with every other tool I use.
For the impatient:
nnoremap <leader>ev :vsplit $MYVIMRC<cr> " Edit my Vimrcnnoremap <leader>sv :source $MYVIMRC<cr> " Source my VimrcA good continuation of this is aliases for editing and sourcing your shell rc file.
I knew about
ci((or whatever other text object), but not aboutca(. So this article was helpful to me for that alone.If this is “intermediate”, then there are at least 20 experts levels on top.
I don’t think it makes sense to look at lists of things you could do with vim. Instead observe yourself and look for one pattern you do often. Then research an optimization for that. Rinse. Repeat. Do it one by one. Vim is around for decades and it will still be there for you in a few years.
I believe learning vim is a daunting task and tutorial resources which show off the power in a nice and friendly way can be a very good introduction to the subject. I see your point about observing and researching optimizations, but at first sight “modal”, “command mode” and even “:wq” might be too much for someone just trying to get their feet wet.
Hey thanks, I appreciate it. :)
I’ve been pair programming a lot 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 folks who were new to vim found both text-objects and composing commands to be pretty mind blowing—so yep, this guide only barely scratches the surface but I just wanted to give newbies a taste for what makes vim so powerful.
I don’t think it make sense to dismiss alternative presentations of information that don’t help you learn as unhelpful for everyone else. I’ve been using vim for just over a decade now, full time, and learned a couple of new tricks just by glancing over this article.
I’m in the same position as you are. Have been using vim for a few years and I still learned something new which I can integrate in my editing workflow.
I’ve been using vim for like 10 years and I don’t think I’ve ever used I, I use A constantly, but I always use 0 to go to the front of a line.
Never occurred to me to look for something because it feels find. I learned a lot by thinking “there should be a better way” and then finding it, looking at these kinds of articles every once in a while is useful for finding unknown unknowns.
I’m similar. I use
Aall the time, and I know aboutIbut yet I find myself doing0ior^iinstead.Try running
vimtutorin your nearest terminal to learn about all of this, and more.One day I sat down and actually read through
:helpin order to get the ideas behind most of the commands. This article sums up most of what I need to get around quickly, but for more advanced stuff Vi[m] never felt intuitive enough for me and certain tasks were simply too complicated to carry out despite being so simple.Then there was vis. It combines most of Vim with Plan 9’s structural regular expressions, concepts such as multiple cursors and more.
Suppose you have a large text and want to edit all occurences of a word as you go: with Vim you’d either record a macro and repeatedly apply it, or (repeatedly) ran some regex substitution (over a range of text) - until you get it right. With vis, selecting all occurences of “foo” is one
:x/foo/away, leaving you with N visual selections. Pressing escape brings you to N cursors, ready to edit them as if they were one.This is easily expandable and aids my natural way of thinking immensely.
Want to sort text? Select it with
vand pipe it through sort(1) with:|sort. Want to include a file or some commands input?:< cat file. Want to pipe text to some command (without reading its output back)?:> cmd.This is intuitive to me. Easily leveraging external commands is a huge win. No built in stuff that can be done with regular shell, no VimL, no legacy support (vim), no built in terminal emulator (neovim), scripting support through Lua.
Note that I’m not trying to sell you something here; whatever works for you is good. It should rather outline what problems I had with Vim and how vis leverages them with a clean design. Editing code gets fast when you don’t have to think about how to carry out your complex/efficient operation successfully - reuse tools in your $PATH and/or break things down to smaller operations while still keeping focus (read: cursors) where needed.
In my experience, not as much as all editor-focused write-ups want you to think. Presumably, you spend much more time thinking what is it that you actually want to do. (Disclosure: my perception is informed by me spending most of the time in Python, as opposed to more text- and repetition-heavy languages like Java.)
Is it? I’m trying to find breakdowns of how programmers spend their time and it’s tricky. I’d suspect it would be something like half our technical time is spent debugging.
I second this. Also for more verbose languages like Java there are usually very good supporting tools, and You usually don’t use a simple editor, but a semantically aware IDE for the task.
Agreed.
I don’t get why people have this need for optimising their text editing so much. They spend so much time trying to learn all these handy keyboard shortcuts and tricks, that the actual time they save when editing text is meaningless.
For me it’s absolutely nothing to do with saving time and everything to do with comfort. It didn’t take long to get over the initial hurdle of just running vimtutor and learning the basic keys to move around and edit. From there it was just editing and occasionally thinking ‘I do this [thing] a lot, is there a way to optimise it? Same for my shell setup. It’s not really a deliberate decision to spend ages customising everything, it’s a gradual process that occurs naturally over years out of curiosity, and it pays off.
Edit: the immediate benefit post-vimtutor was being able to keep my hands off the mouse, and that was enough to make it more comfortable than what I had been doing before. I don’t think I would have bothered if it had been that stressful and time consuming just to get started.
[Comment removed by author]