I once did a lunch and learn at work where I tried to teach coworkers how to use vim efficiently. It turned out to be the absolute worst lunch and learn I ever did.
It's just so unintuitive and trying to teach it in a "here are some good shortcuts that will save you time" way was a near-total waste.
vim is the closest any editor comes to interfacing directly with my brain. Once you learn to make your neurons fire in the right way to move the cursor to the right spot, it's easy and there's no better way to edit code. Describing the neuron firing order to someone else, though, is futile.
It's like learning to to use your fingers to pick something up for the first time as a kid: you just have to try enough times until it sticks.
> vim is the closest any editor comes to interfacing directly with my brain.
It's funny you mention that. Just today, I had this moment where I realized that if someone asked me which key letters are used to move up/down/left/right, I'd have to pause and think about it.
I've been using Vim for years. Like, my index finger rests on the down key, so J is down. I think? And so on... My middle finger rests on the up key, so K goes up? Do I actually have to move my index finger to go left? What is my pinky doing most of the time?
It's just funny how all this stuff is burned into my brain but I wouldn't even be able to tell someone the basics without a keyboard in front of me.
It's even weirder for me as I use the Colemak keyboard layout.
When I first switched to Colemak, around 2010, I remapped the movement keys so that they were in the same physical location as hjkl on qwerty.
Then I realised I'd lost compatibility with other readline based software. So I just learned to use the new, not particularly ergonomic, positions under Colemak.
At this point it's almost always from muscle memory now and couldn't tell you what I press half the time.
Vim is like the Great Glass Elevator, it has a button for moving in every direction and using it since the 90s has been like learning to play a musical instrument.
>Vim is like the Great Glass Elevator, it has a button for moving in every direction
Actually vim is more like the Great Glass Elevator cum Excavator, because it has buttons and levers (to extend your simile) for moving in every direction and performing operations of every kind, and most importantly, all sorts of combinations of the two:
So, if tomorrow, either more movements or more operations were added to vim, they would automatically play well with the older ones.
This is orthogonality (1), and genius, IMO :)
(1) As they mean in microprocessor ISA design (, I think, not being a hardware guy, but have just read about it a little here and there, while doing assembly language programming years ago).
> so J is down. I think? And so on... My middle finger rests on the up key, so K goes up?
Nope, j is down. J combines the current line with the next line, reducing whitespace between to 1 space.
Back when I first figured out what J was doing (having typo'd it regularly) I thought it was useless, then one day I just started reflexively using it when manipulating function arguments.
Likewise, k is up, K looks up the word under the cursor in a man page.
Passwords are the same way for me. I can type my password on a keyboard, but if I have to enter it on my phone, I have no idea what it actually is. Thankfully, a password manager deals with most of my passwords but there is a few that I don't use it for.
A few weeks ago I was unsure of my PIN code because I got it wrong on the first try, the keypad somehow seemed different (I was getting cash, which I don't often do), and I just completely blanked. I got something from a store and paid by PIN there to make sure I got the right code, and then got my cash.
Does the analogy hold for ^M which is carriage return?
Anyway, I remember that stuff. Had a lot of "fun" on Unixes back in the day using things like ^J, ^M, ^H, stty sane, stty -a, stty icrnl, stty onlcr (or is it the other way around), fiddling with termcap and terminfo, and much more ...
> The use of the HJKL keys for moving the cursor in the vi editor and its descendants originated from the ADM-3A [...] The ←, ↓, ↑, → and Home labels printed on the H, J, K, L, and ~ ^ keys were a visual reference to the control characters Ctrl+H, Ctrl+J, Ctrl+K, Ctrl+L, and Ctrl+~ ^ that were required to move the cursor left, down, up, right, and to the top/left corner (or "Home" position) of the terminal, respectively [...] The Ctrl+H and Ctrl+J functions were the standard ASCII backspace and line feed respectively, but the interpretations of Ctrl+K, Ctrl+L, and Ctrl+~ ^ were new to the ADM-3A.
Seems almost a happy accident. I personally like the placement because the most common movement in a document is down and it's placed right under the most dextrous finger, the index finger, by a coincidence between ASCII encoding and the QWERTY layout. Up being the second most common movement was put under the second most dextrous finger. Nice.
Yeah, I think you'd have the same issue trying to teach people to play guitar over the lunch hour. It takes a lot of practice to learn vim but it's super rewarding once you do!
As a side note: "Lunch and learn" is work for me. I have a strikt rule, that whenever someone talks heavily about work at lunch, I consider it a meeting - just as "lunch and work". Therefore I will take a work break afterwards.
I know exactly what you mean. At work people constantly ask me what keys do what and the moment they do my mind goes completely blank. To the point that I even forgot how to use vim for a short while until the conscious part of my brain is preoccupied with something else and suddenly I can use vim again.
I think all quick learning session of vim invariably turns into bootcamp style "learning to code". Jumps straight into what but not how and why.
To know what modal editing is and understand that first is going to help - but then your learning session is over like that without teaching any "tricks".
You can get vim simulators in most editors too. Even Emacs. The interesting question becomes whether you still prefer VIM as an editor. One advantage is you can use the same editor over SSH. If it is not there it is quick to install.
The issue with Vim for me is that it takes years for the keybinds to be picked up as muscle memory. Learning takes effort, people can’t learn everything. And there’s an endless amount of things I can learn other than Vim that will give me a more fulfilling life.
In my case, it only took a few months to be more effective with Vim than without it. Since I spend most of my time working, Vim is a great improvement to my quality of life. The benefits of Vim include not just productivity, but also comfort.
It makes keybindings in vim discoverable, it's quite magical. For example, press g and get a table of all the various commands that follow from there. Press mapleader and get a table of various commands from there, etc.
Edit: On closer look, I've learned that maybe vim-which-key came before that, and guide-key before that etc, there's a long lineage of this too!
Aside: that "one-liner" doesn't "count the words in the file" at all? It just replaces all words with "1" and echos the last line number. I'm confused because this seems so wrong that I may be missing something? Unless the "67 substitutions on 5 lines" message is intended as the "word count", in which case I submit that 1) this is the ugliest thing I've ever seen, and 2) the author of this article doesn't know Vim all that well (there are so many better/easier ways to do this).
It actually increments each word it finds, so while most words will turn to "1", "356" will become "357". I have to imagine this ending up in the blog is the result of a copy-paste mistake, a LLM hallucination, or something similar.
Others have commented on built-in vim functionality for counting words, but assuming the author copy-pasted a similar looking command, they may have intended something like:
:%s/\w\+//gn
Knowing that the n flag will return a count instead of doing the substitute may be useful to know, but I personally don't need a search count very often.
Did you try it? Because that's not what it does. submatch(0) expands to the first submatch, which is the entire thing that's matched, and +1 adds 1 to this, which will a;ways result in "1" here since any string that doesn't start with a digit will be type-coerced to 0.
Anyway, /n being intended sounds likely; I forgot that would report the number of matches. Still very odd how that got morphed to what's in the article.
Also, if I’m seeing this correctly, it only recognises ASCII “words” (a–z, A–Z, 0–9, _), so it’s not even accurate and will over-count words with accents, umlauts, etc.
That one made me cringe hard, the guy would just not use the built-in function or have the decency to sling back into the shell with :! wc -w filename.whatever.
LOL. "simple". I really want to learn vim and be really good at it. I keep trying different tutorials, and I'm starting to be more comfortable with it, but I just keep using sublime text as my main editing tool because it's just easier.
The comments in this post remind me why I use an IDE. Breakpoints, debuggers, auto formatting aren't things I make decisions on every day, they're just built into the tool I use. (I recently moved from visual studio to intellij and friends, and the biggest feature I miss are https://learn.microsoft.com/en-us/visualstudio/debugger/usin... tracepoints. They're like runtime configured logging for compiled languages)
That said, I do use vi bindings for navigation. Stuff like "replace all instances of X with Y" are semantic, and my editor handles them for me. Doing "insert at the end of this quoted string is something I _do_ use. I have gripes with Vi's defaults (hjkl shouldn't be the default because the author had a keyboard with those defaults half a century ago), but overall it's an improvement on arrow keys and a mouse. The best comparison to me is it's like touch typing Vs hunt and peck typing for text editing. I'm not wildly more productive because I can use a handful of shortcuts, but it does remove friction.
What I do want is semantic vim. I spend my day writing code, and despite the fact that I edit text I think in semantics. No, I probably don't care what the next word is, and I don't care to guess how vim is going to interpret `w` when I give it:
What I really want is something that interacts with tree sitter (or the likes) and navigates my code. I want to delete this current block, or this function. I want to jump to the next argument, not the comma in a hard coded string. I want change the last argument of this function, not up until the closing bracket of the first function call in foo(bar(), baz(), 3);
All our apps are containers, so being on the server is a rarity. Quick CLI edits, I use vscode for these days (but am investigating switching to fleet as per the last time it came up here!)
100% agree, I use vim integrations all the time and it annoys me to no end that I cannot act on a function, an identifier, a block.
Text editing is powerful but it is definitely not a seamless interface to my brain when I have to think of how to map what I want to do (eg delete a function) to how I can do it given the specific layout of the text (delete the indentation level with daI but the signature was over several lines so I need a few extra dd).
> hjkl shouldn't be the default because the author had a keyboard with those defaults half a century ago
hjkl are still a pretty good choice for a modal editor. If you’ve learnt standard touch typing, your right hand will be resting on jkl;, so it’s extremely convenient.
The Vi(m) philosophy is to reduce how much you have to move your hands about, so everything is put as close to the “home row” (asdf + jkl;) as possible.
This is why Vim-spinoffs like Helix and Kakoune, while turning the whole keybinding system on its head, are both keeping hjkl. Not for historical legacy, but because it’s actually a good choice.
I disagree that they're a good choice. A good choice is jkl;
> This is why Vim-spinoffs like Helix and Kakoune, while turning the whole keybinding system on its head, are both keeping hjkl. Not for historical legacy, but because it’s actually a good choice.
I had a look this morning and I couldn't find anything to back this claim up. My claim would be it's the opposite, it's what the authors are used to, it reduces friction for other people who might change, but it's objectively inferior than having the keys be the same as the home row keys themselves.
This is the equivalent of saying rsync + a VPS plus some scripts is an equivalent for Dropbox, IMO.
See the start of my original comment for why I don't want to use neovim (Im not spending hours configuring plugins and choosing between three subtly different LSP and treesitter plugins, then choosing a client and server for each). Setting that up involves (first changing editors), learning the details of my editors scripting language, the details of tree sitter, and coming up with a unique set of bindings that don't conflict with neovim's - no thanks.
I personally don't use this functionality so I can't recommend a specific plugin, but if you search for “treesitter”/“tree-sitter” in this list, you will find several of them:
Lets rewrite what I have issue with in clear text: Farming "up-votes/blog impressions" because VIM creator died seems off putting.
Putting VIM in that blog post is unnecessary and I do believe it was posted with bad intentions.
I don't believe article would land on main page if it would not have VIM and it would be only about text editing one liners. Especially when those one liners are not amusing.
Select a block of text with V, press colon and then type:
s/^$/printf("@%d\\n", __LINE__);
To place a line printf on every empty line in the program, to quickly find out where your code crashes on the next run.
Obviates most of my need for external debuggers, and works over serial lines etc where setting up a debugger is going to be a hassle or simply not possible.
This requires that you put have lines between major pieces of codes.
Which I think is a good habit to have anyway. Some people use comments without preceding empty lines (oh why) to delineate code, so they'd have to change the regex a bit to make this work.
No, yours replaces empty lines with 'printf("@%d\n", __LINE);@'. The GP replaces empty lines with 'printf("@%d\n", __LINE__);' The replacement doesn't wrap any code. It annotates that certain points in the source have been reached at runtime. Yours wouldn't compile, which seriously limits its usefulness.
Ah, I misinterpreted. The trick only replaces blank lines, I thought it would work on any line because I thought that `@` was a special output token that would cause vim to insert a copy of the matched input. It isn't.
Then your replacement could be something like:
s/.*/DEBUG_PRINT(&); &;
Which would print out the statement being executed and the line it is at in the program.
Also you’ll want :%s instead of :s, as the latter will only replace on the line on which the cursor is positioned.
Come to think of it, you’ll probably not want this to happen on lines which are themselves preprocessor directives or those with comments, function signatures, or (exclusively) punctuation like with braces. All this to say, I’m sure it could be done, but it gets into the weeds very quickly.
Yes, you can define your own commands to do whatever you want. For things like fuzzy search and frecency sorting, there are a handful of plug-ins and frameworks that can help, including an FZF interface and a few other Vim/Neovim-specific plugins like Telescope and Denite.
if you have already used the command you want recently, just start writing the command you want, then press the up arrow to search through your history for commands that start with whatever you've typed so far.
also, a nit pick, if you use Magic mode (\v), that pattern gets way better:
My favorite one liner is :!}fmt which on Linux and UNIX systems runs from where the cursor is, through to the end of the paragraph though the fmt(1) command (which wraps words etc.) When I edit a file that has no line endings this can create a readable document for me.
You can do that by setting textwidth to a value, say "set textwidth=80", and hitting the "gq" action. So to format the current paragraph something like "gq}" would do the same as your snippet
I like fmt better because it works on all vi's. It's also closer to the UNIX philosophy of doing one thing and doing it well.
Also, it's not just fmt you can use. Want to sort a paragraph of lines? !}sort^M and you're done. Or reverse sort till the end of the file with !Gsort -r^M etc.
Really, all UNIX commands are integrated into your editor, and that's the beauty of it.
>Or reverse sort till the end of the file with !Gsort -r^M etc.
Right. Or flip the case of a section of text, even of an arbitrary block of lines demarcated by marks set by vi(m) commands like ma and mb and the like, by filtering it through tr.
Or filter another section through sed or awk or even through a Unix pipeline, to do whatever you want.
And with just a little practice, you can become fluent and fast with all of this, and it improves your productivity a lot, apart from being fun and creative.
If your cursor is within two quotes on a line, it will select everything inside those quotes to (c)hange, (y)ank or (d)elete or whatever you want. Great if you're the sort of person who writes HTML by hand all the time.
I habitually use visual mode for a lot of stuff like that so quick flash shows me what was affected (in case of typo). If the highlighted part isn't what I expected I instantly know to undo, rather than having to think about the resulting text for a moment.
Same. Which shows a weakness of vim, I think it’d be much more usable if it had the verb last: iw would select the word then you can delete, yank, or even extend the selection knowing exactly what you’re going to operate on.
I think kakoune works like that, but I don’t have the will to learn another editor and vi is what’s available everywhere anyway
You can also use yi" to yank it immediately without selecting it first (replace y with c or d to change or delete, respectively). Replace i with a to include the quotes ("around" rather than "inside"). Replace " with ( [ or { to match other kinds of bracketing characters. And include a number to go more than one set out.
E.g.
y2a(
means yank everything inside (and including) the second nested pair of parentheses out from the current point.
Tbh I hate that vim keeps wanting to make me count. I don’t know if it is the first, second or third nested pair of parentheses, and the time for me to count is probably similar than the time to just select with the mouse. I struggle to believe anybody actually counts when using vim , whether it’s levels of nesting or number of lines.
I wish vim was better at showing what you’re going to operate on, and edit it before the operation. Eg a( could select out of the first parentheses then n to extend until everything I want selected is, then y
For programming in languages where indentation means a nested block:
>>
and
<<
indent the current line right and left by one indent position respectively, typically a tab or 4 spaces, though I need to check whether it works for spaces.
Prefixing those with a number n will indent n lines, starting with the current one.
This works in all filetypes, and the indentation amount is set by shiftwidth. Whether tabs or spaces are inserted is controlled by expandtab (for spaces) or noexpandtab (use tabs).
You can use any navigation command as the target, I find myself often using
>You can use any navigation command as the target, I find myself often using
> >}
>to indent every line until the end of the block.
Yes, that's a good one for code in languages where } marks the end of a block, such as C, C++, Java, etc.
I also use
>G
to indent from current line to end of file in a text file, or
1G>G
which is 1G to go to line 1, and then >G to indent to end of file, which indents the whole file, which can be useful for printing on paper, more so when combined with other options like shiftwidth, !fmt, etc. (also mentioned in this thread).
And many other such combinations of the indent operation and some movement, for structuring text or code, are possible.
All such combinations are based on the same principles mentioned in the Stack Overflow "grok vi" comment that I posted about in this thread:
It doesn't seem to work -- except it says "xxx substitutions", so you can assume it found exactly xxx words. Besides, it changes the original text so you need to undo. Lastly, why is it so complicated? What is the purpose of submatch()? And why echoing the number of the last line?
I also snarked a bit when I saw your word count example, but immediately reversed course when I saw the JSON formatting one-liner. I will use this. I will use the hell out of it. Thanks!
I don’t know. I’m assuming I should install jq (or see if I already have it?)
Here’s the problem I have: I don’t often have to format unformatted JSON, but when I do, it’s almost always an error message I’m trying to parse in order to track down a bug. So I tell myself “I should really figure out how to automate this…I know it’s obviously possible, but I just really wanna fix this bug right now, so I’ll do that later.”
And then the next time it happens, I curse myself for not having researched that, and promise to do it before the next time.
So I’m just happy that I stumbled across this page. Now I don’t have to remember to research it :)
One of the beautiful things about vim is that they have multiple ways to skin the cat and, as such, you develop your own mode of using it.
For example to navigate within a single line you can:
- f[character] (jump to character)
- w/e (jump word by word)
- A (jump to end, navigate from there)
- / (search!)
- h/l (move left/right)
- even more ways!
What’s funny is that, theoretically, some of these movements are more “efficient”, for example jumping to a specific character is a lot faster than going character by character. However, I found that I often go character by character or searching instead of f[] just because my brain finds it easier to move that way than to think “what character is that”. I use massive jumps when finding a line; but once on that line, I use very slow movements. Now, it’s totally less efficient, but it’s how my brain/fingers navigate most naturally even after repeated attempts at to train myself to use “better” methods. Perhaps my habits will change over time, but regardless it is remarkable how “personal” vim can be.
I would advise anyone who wants to master VIM (and NeoVIM) to get used to all the different ways to move through a document. Here's a good wallpaper about that:
Ever now, after decades of use, I try to incorporate the most efficient methods of moving around the document and around the screen. Sometimes, when I've just held down movement keys (such as 'hjkl') to get to a specific location, I'll go back to where I was and, for example, use the find character command instead as practice.
Oddly I often navigate in a line by typing “f “ (f space) then press . repeatedly until I’ve gotten to the right place. Never occurred to me to navigate within a line using / but that ought to be faster most of the time
I tried to switch to it as my PHP IDE from PhpStorm, replicating each feature with config and plugins. Finally I realized I couldn’t get EA Inspections working in vim, the interface just doesn’t exist. JetBrains has a new CI tool for their inspections so that may provide a way with enough effort.
Reformats the current long line into a paragraph of the specified width. If a word overruns the column width limit, the entire word is moved to the next line.
Awesome, thank you. I'm forever manually adjusting block comments to be a sensible width so this will help. Probably asking a bit much but do you know if there's a command that can operate on a visual line selection and do the same? e.g. I come across a block comment, add to it, then want to re-width it. Worst case, I guess I could create a command to collapse the lines first then run gqq.
The command you want is just gq. In normal mode it accepts a motion, eg gqip or gq}. And it works in visual mode as well. The gqq command is a special case for the current line. Personally I use https://github.com/kana/vim-textobj-line which defines a text object for the current line and maps it to _, so gq_ also formats the current line.
fyi _ is a built-in motion; that plugin defines a couple others: il and al, which are specifically characterwise (vs. _ can be either that or linewise)
gq is a linewise operation anyway, so gq_, gqil, and gqal all have the same effect
Lesson two after learning how to quit vim should be that q: opens command history. If I had a dollar for every time that window opened and left me wondering 'wtf, quit damnit', I'd have at least 12 dollars.
Pretty confused about this post and comments. Seems everyone is just using custom regexps or piping buffers to external commands. That's how I as an emacs user occasionally use vim. And that's because I don't know vim at all and this way I can work around my ignorance.
I refuse to believe vim power users use it like this.
I don’t think that this list is supposed to be an accurate representation of how people typically use vim. More likely this list was compiled precisely because these uses are somewhat non-standard / non-obvious and therefore worth sharing. Having said that, I do believe that using external tools is much more idiomatic for Vim than Emacs.
I never pipe buffers, but I do use sed regex replacement pretty often. Like many other vim aspects I always feel it’s clunky though: vim is a _text_ editor when I want it to be a _code_ editor. I don’t operate on paragraphs or regular expressions, I operate on functions and identifiers and imports.
It's one aspect of using vim, to use the s or g commands efficiently IMO. But it's not as important as using the regular command + movement vim language stuff.
This is a neat one-liner if you don't want to install vim-fugitive on a temporary machine just for 'Gvdiff': set diff crb | vnew | exec "r !git show HEAD:#" | set diff crb
Shows git diff with head - modify git show command to taste.
I have these in my .vimrc, to display and auto-trim trailing whitespace:
augroup trailing_whitespace_show
autocmd!
" Make trailing whitespace red.
autocmd ColorScheme * highlight ExtraWhitespace ctermbg=red guibg=red
autocmd BufWinEnter,InsertEnter,InsertLeave * match ExtraWhitespace /\s\+$/
" Can slow things down, but show trailing whitespace as red while typing.
autocmd InsertCharPre * match ExtraWhitespace /\s\+$/
augroup END
augroup trailing_whitespace_kill
autocmd!
" Delete all trailing whitespace on-save.
autocmd FileWritePre,FileAppendPre,FilterWritePre,BufWritePre *
\ let w:wv = winsaveview() |
\ :%s/\s\+$//e |
\ call winrestview(w:wv)
augroup END
I do the same. For Neovim users, Command Center is a neat customisable command palette (e.g. from VsCode) menu, but there's a few around. I typically create a command but also add it to command center, whose open mapping I have set to shift+enter. You can then fuzzy find command names/content which helps for those commands you don't use all that often.
I guess it depends. There's almost always multiple ways to do anything in Vim and pros and cons to each.
Using a mapping will save you time if you use the same regex often but you can end up having to remember a lot of shortcuts. I find I forget rarely used mappings.
If you learn the Vim command line and regex well it can be quicker to just type what you want on demand and then use one of the methods repeating it. Then forget about it till the next time you need it.
It's also helpful if you have to use configured Vim occasionally.
As (neo)vim user, this article is quite low on the tier list for useful information about vim IMO. I appreciate the vim discussion here but not much more to gain from this posting unfortunately.
VSCode runs a desktop app as well as in a browser. You knew that though.
And I use VSCode on a 10 year old desktop. VSCode itself is very light. It's the extensions that sometimes have performance issues. Microsoft's C++ one is by far the worst offender.
Because empty octets of an IPv6 address can be elided (1:0:0:0:0:0:0:2 can be represented as 1::2) the regular expressions are actually quite painful. I wrote a library for JavaScript called `ip-address` that can generate regular expressions to find all forms of a specific address. Here's the regular expression for all forms of 1::2:
vi and vim are atrociously bad. y’all got stockholm syndrome
vim may be 10% less awful, but it’s still garbage
> When using Vi in insert mode, you cannot move around without first hitting Esc then again i or a. Vim fixes this by allowing you to use the arrow keys to move around in a file while in insert mode.
Speaking for myself, my reason for using vim is to keep my hands on the keyboard and reduce mouse usage. The other benefit is that I can stay in the terminal instead of having to switch to a GUI editor.
If those benefits don't sound enticing, then I could how it might seem unappealing.
It's just so unintuitive and trying to teach it in a "here are some good shortcuts that will save you time" way was a near-total waste.
vim is the closest any editor comes to interfacing directly with my brain. Once you learn to make your neurons fire in the right way to move the cursor to the right spot, it's easy and there's no better way to edit code. Describing the neuron firing order to someone else, though, is futile.
It's like learning to to use your fingers to pick something up for the first time as a kid: you just have to try enough times until it sticks.