A Vim Guide for Advanced Users(thevaluable.dev)
thevaluable.dev
A Vim Guide for Advanced Users
https://thevaluable.dev/vim-advanced/
83 comments
I notice it mentions Ctrl-a and Ctrl-x which "increment or decrement any number after the cursor on the same line". I hate these shortcuts because several times I've accidentally pressed them (e.g. on some level thinking I'm in Spacemacs or in readline) and introduced a hard-to-find bug into my code without knowing it.
Agreed. I love vi, but this is almost always an anti-feature.
To disable, add these lines to .vimrc:
To disable, add these lines to .vimrc:
map <C-a> <Nop>
map <C-x> <Nop>Shows how crucial customizability is because I don't think I can work without being being able to rely on <c-a/x>, and more importantly g<c-a/x>.
Won’t you spot that through you source control?
They can be quite useful, but I just stopped using them due to muscle memory of Ctrl-a for screen / tmux.
Having suffered through learning highly configurable software tools independently enough times, I agree completely with "digesting one or few commands" at a time works better for me too.
Spitballing:
We could probably make a general solution for organically producing "learning guide" if power users 1) share their custom configurations and share the frequencies of commands they use.
Start with the general configuration, knowing nothing about the commands the tool offers. The learning guide is just a queue of "here's the most common config edit that you don't have" and "here's the most common command that you don't know about."
We are already share configs with eachother via the dotfiles pattern. We somewhat share command patterns via coding streams. Seems doable.
(In general, making it easier to learn new tech and for devs to share / refresh the learning material for a new tech seem underdeveloped.)
Spitballing:
We could probably make a general solution for organically producing "learning guide" if power users 1) share their custom configurations and share the frequencies of commands they use.
Start with the general configuration, knowing nothing about the commands the tool offers. The learning guide is just a queue of "here's the most common config edit that you don't have" and "here's the most common command that you don't know about."
We are already share configs with eachother via the dotfiles pattern. We somewhat share command patterns via coding streams. Seems doable.
(In general, making it easier to learn new tech and for devs to share / refresh the learning material for a new tech seem underdeveloped.)
If I could add one thing to the list I would include `cib` as equivilent to `ci(` for changing everything in a set of parentheses (or brackets for the mnemonic's sake). For me at least the `b` is easier to reach than the `(`.
I need to use `z` for refocusing more
I need to use `z` for refocusing more
I agree. That said, I also like to have a more complete guide and pick and choose what could be useful for me.
I recently picked up a copy of "Practical Vim" https://pragprog.com/titles/dnvim2/practical-vim-second-edit... based on a recommendation from a comment on HN. The first chapter mentions the built-in `vimtutor`
I never it existed! It was incredibly helpful with some features I'd never used such as Put, Replace and Visual mode. If you have vim, you should just be able to run `vimtutor` in the command line. If you have trouble, you can run `:help vimtutor` within vim.
I never it existed! It was incredibly helpful with some features I'd never used such as Put, Replace and Visual mode. If you have vim, you should just be able to run `vimtutor` in the command line. If you have trouble, you can run `:help vimtutor` within vim.
Yeah, I've known and used "vi" for a couple of decades, saw someone use visual mode in a video a few months ago, and it blew my mind.
I still don't know how to do project navigation in vi, as I mainly use it for editing config files. I used emacs back in the day, but vscode is what I'm currently most comfortable with for moving between files in a large, deeply nested project.
I still don't know how to do project navigation in vi, as I mainly use it for editing config files. I used emacs back in the day, but vscode is what I'm currently most comfortable with for moving between files in a large, deeply nested project.
Use fzf for file navigation and perhaps vim-vinegar. When you open Vim, use :cd to change to your project directory and you’re ready. Use :term to start stuff, e.g., a local web server or whatever. Use fzf to navigate between open buffers.
You might find the ":NERDTree" plugin useful for project/directory navigation:
https://catonmat.net/vim-plugins-nerdtree-vim and https://github.com/preservim/nerdtree
https://catonmat.net/vim-plugins-nerdtree-vim and https://github.com/preservim/nerdtree
The "g" namespace is one of the few things I find annoying in Vim (which I like a lot). It is a grabbag of operations at cursor position ("gu", "gU"), mode switches ("gn"), file operations ("gf") and... weird stuff? Like, "ga" (prints the ascii value of the character under the cursor). This really does not help with memorizing the commands.
On the plus side, it enables "* + cgn + ." which is a neat way to do quick multiple substitutions, so yay I guess?
On the plus side, it enables "* + cgn + ." which is a neat way to do quick multiple substitutions, so yay I guess?
I imagine "g" as Vim's builtin leader mappings due to all other keys already being mapped to something else.
The "g" namespace is a dumping ground for "alternate" versions of things that already have normal-mode mappings.
Personally I think most of the normal mode mappings make no sense, other than the core motions and "q". A lot of precious "one-key" mappings are kind of wasted. You can of course override them, but it feels very "bolted on"
One of my high hopes for Neovim is that eventually they will start migrating the hard-coded default mappings to something more akin to a default config layer, which will be easier to override or disable. They have already started doing this for built-in commands, e.g. :cscope has been removed.
Personally I think most of the normal mode mappings make no sense, other than the core motions and "q". A lot of precious "one-key" mappings are kind of wasted. You can of course override them, but it feels very "bolted on"
One of my high hopes for Neovim is that eventually they will start migrating the hard-coded default mappings to something more akin to a default config layer, which will be easier to override or disable. They have already started doing this for built-in commands, e.g. :cscope has been removed.
Maybe it's g for "grabbag" ...
Agreed, that's the only time I find myself missing Emacs' which-key. (Looks like there is https://github.com/liuchengxu/vim-which-key for this.)
It's on the homerow in the middle of the keyboard, equally accessible to both hands. If it were a symbol key I suspect there would be less perplexity, but because it's a letter key users are left wondering what the mnenomic is :)
I never knew about `ga`, that's pretty useful, thanks!
The best guide is built in to Vim but sadly often overlooked.
https://vimhelp.org/usr_01.txt.html#usr_01.txt
https://vimhelp.org/usr_01.txt.html#usr_01.txt
Table of contents for this user manual: https://vimhelp.org/usr_toc.txt.html (`:h usr_toc.txt`)
Here's the reference manual: https://vimhelp.org/#reference_toc (`:h reference_toc`)
There's also a cheatsheet: https://vimhelp.org/quickref.txt.html (`:h quickref`)
Here's the reference manual: https://vimhelp.org/#reference_toc (`:h reference_toc`)
There's also a cheatsheet: https://vimhelp.org/quickref.txt.html (`:h quickref`)
Reading the docs and searching into it on a regular basis is the single best advice I could give to Vim users wanting to improve. The odd cheatsheet, the post with a few tricks and cool plugins, all those can be well and good, but nothing beats sitting down and reading the docs. I've been use Vim daily for 10+ years, and I still check help files very regularly. Knowing _how_ to search efficiently is also a skill worth acquiring.
Incidentally, the same advice apply to Bash: just read the man page, and search into it each time it is needed. It is just worth it.
Incidentally, the same advice apply to Bash: just read the man page, and search into it each time it is needed. It is just worth it.
I tried to go through it multiple time, but I couldn't:
1. It's way too long, the complete stuff is ten of thousand of lines. 2. It goes into needless details, especially at the beginning (the "finding help" section is intense for example). It turns me off each time. 3. It's too dry, not really enjoyable to read to me.
1. It's way too long, the complete stuff is ten of thousand of lines. 2. It goes into needless details, especially at the beginning (the "finding help" section is intense for example). It turns me off each time. 3. It's too dry, not really enjoyable to read to me.
I think the best explanation of vi is the seminal post:
You don’t grok vi
https://stackoverflow.com/questions/72498282/your-problem-wi...
You don’t grok vi
https://stackoverflow.com/questions/72498282/your-problem-wi...
I think you meant this one:
https://stackoverflow.com/questions/1218390/what-is-your-mos...
https://stackoverflow.com/questions/1218390/what-is-your-mos...
I love how this elaborate reply never mentions the obvious thing that the OP wants, text objects.
This is really great.
I’ve recently switched to Helix editor after 10 years of vim and haven’t looked back. If you’re looking for something a bit simpler, zero configuration, but with the same philosophy as vim (select -> action) give it a try.
I’ve recently switched to Helix editor after 10 years of vim and haven’t looked back. If you’re looking for something a bit simpler, zero configuration, but with the same philosophy as vim (select -> action) give it a try.
What annoyed me with helix was that invisible characters are treated the same as characters. That means your cursor can be positioned after the end of the line, on the '\n' and just sit there.
For instance, if you press "A", you are now after the \n of the end of line, and pressing backspace will remove the \n, joining with the line below.
I tried to ask whether that peculiar behavior could be toggled off somehow, but was welcomed by a wall of extreme purism on how treating differently visible and invisible characters would break the character model of the editor...
I'm too old to entertain the argument, and will just stick back to vim. Maybe its character model is unpure, but at least it's understandable by a mere mortal like me.
For instance, if you press "A", you are now after the \n of the end of line, and pressing backspace will remove the \n, joining with the line below.
I tried to ask whether that peculiar behavior could be toggled off somehow, but was welcomed by a wall of extreme purism on how treating differently visible and invisible characters would break the character model of the editor...
I'm too old to entertain the argument, and will just stick back to vim. Maybe its character model is unpure, but at least it's understandable by a mere mortal like me.
There is a pending pull request partially addressing this:
https://github.com/helix-editor/helix/pull/4204
Treating newlines as regular characters allows you to use them in motions: t<Enter> will select text until end of the line for example.
> with the same philosophy as vim (select -> action)
"select->action" is definitely possible thanks to visual mode but it certainly is not Vim's "philosophy", which would be more in the line of "action->object".
"select->action" is definitely possible thanks to visual mode but it certainly is not Vim's "philosophy", which would be more in the line of "action->object".
Ha yes, I meant to say opposite philosophy, ugh. Vim is command -> object but Helix it’s the other way around. In Helix you select first then do something.
Zero configuration sounds like the opposite of why I like vim. I want things to work exactly how I want them to work. Vim’s composability of normal, day-to-day actions you already know is its best feature
Im also in the process of switching to Helix and Zellij. I like the minimal configuration of Helix compared to going through multiple git repos just to find the needed neovim config and adjust them to taste.
Holy cow I switch to Helix a couple months ago but its my first time hearing about Zellij and wow this is too powerful with Helix! thank you so much for this!!!!!
Zellij just looks like Tmux with tabs. Am I missing something?
> with the same philosophy as vim (select -> action)
but Vim is not select -> action?
say `d2w` (to delete two words after the cursor) it's action then selection
but Vim is not select -> action?
say `d2w` (to delete two words after the cursor) it's action then selection
But the massive plugin ecosystem and the endless configuration possibilities is part of the charm!
Are there any good VSCode extensions that support helix-style input?
Yes, you'll have to tweak the default keybindings a bit to match Helix but I am using dance successfully:
https://github.com/71/dance
https://github.com/71/dance
A useful Vi/m feature is splitting viewports with Ctrl-w + v/s.
Maybe it's so basic it never gets mentioned but I find a lot of people under utilize it.
Another good one is typing . to repeat previous command. You can do
Ctrl-w + v == split current viewport vertically
Ctrl-w + s == split current viewport horizontally
Ctrl-w + = == resize viewports to equal height/widths
Ctrl-w + j == move one viewport down from current viewport (if available)
Ctrl-w + k == moves one viewport up from current viewport (if available)
Ctrl-w + h == moves one viewport to the left from current viewport (if available)
Ctrl-w + l == moves one viewport to the right from current viewport (if available)
Maybe it's so basic it never gets mentioned but I find a lot of people under utilize it.
Another good one is typing . to repeat previous command. You can do
A, "something"
Thanks for this. I still remind having one of the kindest TAs of my undergrad remark in a thick Ukrainian accent “ahhh, vi, a true master” and move on to helping folks use pico during a *nix programming primer.
(Sometimes ppl would demand I follow the syllabus. I don’t like to follow the guidelines.)
You could always use emacs if you’re into that kind of thing, but telling them you should use pico is like telling them to clean their dorm with equal parts bleach and ammonia soaked in castor beans.
(Don’t do that.)
(Sometimes ppl would demand I follow the syllabus. I don’t like to follow the guidelines.)
You could always use emacs if you’re into that kind of thing, but telling them you should use pico is like telling them to clean their dorm with equal parts bleach and ammonia soaked in castor beans.
(Don’t do that.)
What, an explanation of `g` but no mention of `gq`?? :)
There are lots of useful g commands. See also thread above talking about g commands. My favorite is g;
I didn't know about many of them, so TFA was very useful for me!
The most annoying thing about vim/vi is that after using it for twenty years I still don't know all the useful things you can do with it. To put that in context, I find vim indispensable. And adding stuff like markdown preview and fzf integration just makes the problem worse. Sigh.
False. The most annoying thing about vim is that I can’t type properly in web input boxes, email clients, rich text editors… I want vim in all the places.
I was doing a live coding challenge in some online editor the other day, and I think they were really confused as to why I kept typing "h" and "k" and "g" all over the place.
This is me, and it has gotten worse since using the neovim extension with vscode.
I used to have a mental cue that terminal was hjkl; and GUI was pointy-clicky.
Now if I ever go to something like intellij IDEA, I'm spamming home row all over the code :)
I used to have a mental cue that terminal was hjkl; and GUI was pointy-clicky.
Now if I ever go to something like intellij IDEA, I'm spamming home row all over the code :)
IntelliJ has a pretty good vim emulation plugin, actually.
Firenvim may be a partial solution: https://github.com/glacambre/firenvim
You can do this with Emacs Evil Mode using the emacs-everywhere package.
https://github.com/tecosaur/emacs-everywhere
https://github.com/tecosaur/emacs-everywhere
I don't care if i'am not using every feature in Vim. I gave up on NVIM, because i was completely done with configuring plugins with bad documentation, no good defaults. For every plugin i needed to learn more and more shortcuts. After an update some plugins were broken etc. I just now stick with VSCode with the NVIM plugin.
Previous discussion: https://news.ycombinator.com/item?id=26284618 (603 points | Feb 27, 2021 | 172 comments)
Twenty years on VIM and I didn't know:
gI - Insert text at the beginning of the line, no matter what the first characters are.
As a beginner user for decades, some basic like visual mode is not covered even in the intermediate one. And so is plug-in not in advanced one.
Not sure about this arrangement.
Not sure about this arrangement.
This is a good list. I need to get more comfortable with quickfix and location. I’d like to build something like the fzf plug-in some day
I’d highly recommend folks learn some vimscript. Mappings, functions, commands. My most recent use for these was for quickly generating a lot of permalinks for building internal documentation. Macros and argdo are also invaluable for large scale edits.
I’d highly recommend folks learn some vimscript. Mappings, functions, commands. My most recent use for these was for quickly generating a lot of permalinks for building internal documentation. Macros and argdo are also invaluable for large scale edits.
The range injected for you by Vim when you do `:` in visual mode? Registers? Substitutions? Really?
There is nothing advanced about this and nothing to learn for an "advanced user".
There is nothing advanced about this and nothing to learn for an "advanced user".
I need an Advent of Vim to practice all of these
I am struggling to get started on a German keyboard. Some special characters are hard to reach.
I recommend using the American keyboard layout if you're doing anything remotely programming related, otherwise all the special characters are just way too annoying (even though personally there's also a few of those in the American layout that are suboptimal, but a keyboard only has so much space...).
If you frequently find yourself needing German (or other European) symbols like ä then you can also look into using EurKEY [1] which is basically the American layout but gives you easy access to the "umlauts".
[1] https://eurkey.steffen.bruentjen.eu/
If you frequently find yourself needing German (or other European) symbols like ä then you can also look into using EurKEY [1] which is basically the American layout but gives you easy access to the "umlauts".
[1] https://eurkey.steffen.bruentjen.eu/
Have you tried the US-International layout[0]? It's basically the standard QWERTY US layout but ", ', ^ are dead keys used to generate diacritics.
If you press " followed by o you get ö.
' + e prints é.
The only thing to get used to is that if you want quotes for example, you need to press <space> or another character that doesn't accept accents after the key. I used this layout for French and it's way better than the weird French AZERTY layout.
[0] https://en.wikipedia.org/wiki/QWERTY#US-International
If you press " followed by o you get ö.
' + e prints é.
The only thing to get used to is that if you want quotes for example, you need to press <space> or another character that doesn't accept accents after the key. I used this layout for French and it's way better than the weird French AZERTY layout.
[0] https://en.wikipedia.org/wiki/QWERTY#US-International
Tbh I have not. I was afraid of being slower to type or making more mistakes. But I think at least it is worth to try. Thank you.
I enjoy using Vim, but I feel like it's a pain to use with lesser known languages. Especially when it comes to compiling and such.
Is there such a thing for emacs?
Check out https://www.masteringemacs.org/
There is the info manual.
C-h i
C-h i
> Is there such a thing for emacs?
Meh. I used vim for 20 years. Got to the point of tricking it all out with some of the full-blown ~/.vim configs you can just grab from GitHub. Some of the advanced tips on that site take it into the realm of being emacs. But I found that I was basically trying to get it to be... a GUI, with NERDtree and the lot. When I discovered Sublime Text, and multiple cursors, I quickly gave up on vim. I develop web applications (mostly). I'm pointing and clicking all throughout the process, since web pages are inherently graphical. I still haven't masted all of the keybindings for ST, but I think that being obstinate about keeping my hands on the keyboard when I'm editing is a waste of mental effort. YMMV. I think my lack of being able to fly through editor options without using a mouse cost me a job once, but if a place is going to fetishize that over being a deep expert with 25+ years of experience, go for it. I can solve business problems with software.
* Edited for "Sublime Text," though I don't know why I'm bothering, as this is being downvoted.
* Edited for "Sublime Text," though I don't know why I'm bothering, as this is being downvoted.
I think it's being downvoted because people may be interpreting the opening "meh" as too negative. Or possibly not meeting the standards of Hacker News.
Fair enough.
What's the point of leaving a long comment on a post about vim detailing how and why you aren't interested in vim, or about how vim doesn't meet your needs? There are lots of posts here on HN about things that don't interest me, but probably not everyone needs to know about it.
Well, my point was more about how, in the era of GUI's, when working ON GUI's, the idea that vim is somehow miles "better" doesn't necessarily hold up, and measuring how deep your vim knowledge goes is a bit of a nerd dick measuring contest these days, but your point is taken.
> Well, my point was more about how, in the era of GUI's, when working ON GUI's, the idea that vim is somehow miles "better" doesn't necessarily hold up, and measuring how deep your vim knowledge goes is a bit of a nerd dick measuring contest these days, but your point is taken.
But who was making that claim? Yours was a top-level comment, so I can only suppose that it was responding to the article; but I do not find your claim in the article—specifically, I only find two occurrences of the quoted word ‘better’ in the article, neither of which is even mentionining GUIs.
Myself, I have never used any other editor, GUIs included, that matches the experience I have with vim, and I'm a pedestrian user of vim at best. As long as vim keeps existing, it doesn't bother me that other people prefer other experiences; so why inveigh against people with different tastes to yours, or different uses for their text editor from yours, who prefer vim and, preferring it, want to learn how to use it well?
But who was making that claim? Yours was a top-level comment, so I can only suppose that it was responding to the article; but I do not find your claim in the article—specifically, I only find two occurrences of the quoted word ‘better’ in the article, neither of which is even mentionining GUIs.
Myself, I have never used any other editor, GUIs included, that matches the experience I have with vim, and I'm a pedestrian user of vim at best. As long as vim keeps existing, it doesn't bother me that other people prefer other experiences; so why inveigh against people with different tastes to yours, or different uses for their text editor from yours, who prefer vim and, preferring it, want to learn how to use it well?
pardon me, but what is ST?
Most advanced guides throw a lot at you at once. Digesting one or few commands at a time works better for me to really make it stick (and that is the goal right?)