The key is to almost always be in command mode. I am only in insert mode briefly to add or change text. The power of Vim comes from its terse command language, so you want to be in command mode most of the time. I find myself reflexively hitting Esc or Ctrl-[ in other programs because I have drilled this into my mind.
> I just can't see where this "efficiency" is supposed to be at all.
I did not see the efficiency myself until I witnessed a Vim master do some extremely complicated bit of text editing in seconds. I think that most people will not see the value of Vim until they witness something like that.
> If you tell me I'm supposed to spend 4 weeks reading VimTutor to gain efficiency in Vim, I could probably become more efficient faster in VS Code by learning all of its keyboard shortcuts. Btw Ctrl+/ comments the current line.
I personally found Vimtutor boring, if I recall correctly, so I did not use it to learn Vim. I just started to use Vim for all of my coding for several weeks during a slow period at work. I had a printout [1] with all of the keys next to my monitor for several weeks. That was necessary to get muscle memory for every action. I also read a lot of "Learning the vi and Vim Editors". That helps you get into the mindset about how to use the Vim command language. My point is that there are many ways to learn Vim and you can pick which way works best for yourself.
[1] http://www.viemu.com/a_vi_vim_graphical_cheat_sheet_tutorial...
Do people know they can use regex substitutions in VS code, for example? I'm sure Vim can do this as well, even Notepad++ has it, but it's the sort of feature most people don't know about because they just don't use regex very often.
The key to Vim mastery is realizing that every key you press is a command in the language of Vim. Once you realize this, you can construct complicated sequences of commands that do exactly what you want without having to do it yourself manually. This is why I say that it is difficult to see how much more efficiency you can get without witnessing it yourself. It is a fundamentally different way of doing text editing.
Let's just focus on navigation for a second. Yes, you can type things like "10j" to go down 10 lines. Yes, you can type "10}" to go down 10 "paragraphs" (could be functions, etc.). Or you can type "/text" to find the next instance of "text", and then type "10n" to go to the 10th instance. Once you realize all of these things, you start to think about navigating the code a lot differently, since you realize that you can make your code very structured and make it incredibly easy to navigate with just the keyboard.
Let's now focus on something that would be really tedious to type but would happen instantly in Vim. Let's you you want to make an array of 100 elements for some reason. If you had to type that manually, you could have an off-by-one error or something. It's really tedious and not something you want to do yourself.
Instead, you can type this in Vim:
i
array = [
Esc
99A
0,
Esc
A
0]
Esc
and you have an array with exactly 100 zeros. This is a simple example. You can continue this to much more complicated structures. That is the power of Vim.
(Yes, if this is Python you can do the same thing with "array = [0] * 100". My point is to illustrate Vim's command language and how it changes how you approach text editing.)
I love Vim, and agree with this, but using this as a reason to learn Vim feels silly to me. How often do truly complicated text editing tasks come up for most programmers? Vim is really handy for when I maybe need to cut and paste some data from a web page and get it into CSV, but that's just not a common enough task for me that I'd actually recommend anyone else learn it for that purpose.
"Novices are not the only victims of modes. Experts often type commands used in one mode when they are in another, leading to undesired and distressing consequences. In many systems, typing the letter "D" can have meanings as diverse as "replace the selected character by D," "insert a D before the selected character," or "delete the selected character." How many times have you heard or said, "Oops, I was in the wrong mode"?"
However the larger attempt and redo problem you highlighed is mitigated in a modal editor that does selection first (not vim) instead of action so you get a preview of what you will delete before hitting it, you can also expand it.
I did give up vim for the same reasons, but I am happy with Helix.
I won’t deny that I still make lots of errors, I still use vscode for other features like folder search and replace, easier diff comparisons
This is pretty much what Visual mode does. V4jd is
* V: enter visual line mode. * 4j: select the next four lines (in addition to this one) * d: delete.
The selection is highlighted before the delete command, you can change the selection range, etc.
I use visual mode to replace stuff all the time: V10j:s/foo/bar/g It even shows the changes interactively.
The find and replace is more at folder level with vscode previews only terminal equivalent I know is serpl
I frequently use c (change) on my visual selections, type in new code at the point where it was removed, then use p to paste the old code somewhere else.
Vim tells you the mode though!
Insert -> Normal/Visual: ESC, Ctrl+c, or Ctrl+[. You could also do something like, while in Insert mode press Ctrl+o to do "one movement" (e.g. "i234[Ctrl+o]^1[Ctrl+c]", or maybe, "ihelo world[Ctrl+o]2Fll[Ctrl+o]$![Ctrl+c]" -- don't type the "[" and "]").
Normal -> Insert: well... it depends on where you want to insert.
> But in practice I can't count so I cut the wrong number of lines
Sometimes you don't need to keep track of the number of lines. But, if you really wanted to, you could do something like:
:set relativenumber
If it's code or text you could also use sentence ("(" and ")") or paragraph ("{" and "}") movements like "5d)" (delete the next 5 sentences); "d{" (delete up to the previous paragraph). There's a bit of jank when it comes to code though, but there's some support for it (or maybe I'm just doing it wrong).
> then I have to look up how to undo because obviously Ctrl+Z doesn't work
"u" for Undo, Ctrl+r for "redo". ":help undo" goes into _way_ more detail, and it does get complicated. I don't think I've needed anything past section 2.
> I just can't see where this "efficiency" is supposed to be at all.
The "efficiency" comes with investment, which you can get with any editor.
> If you tell me I'm supposed to spend 4 weeks reading VimTutor to gain efficiency in Vim
I didn't go through vimtutor for a very long time. You can become a reasonably okay Vim user, but it does take some investment. On the order of weeks is probably correct.
But honestly, VSCode is fine too. Notepad is... probably fine.
Doesn't sound more efficient than VS code to me.
Absolutely! It takes learning relatively few command/motion combos before you are really cooking. The commands are fairly composable as well. I rarely find myself without being able to find a command that can't do what I want. To be fair it takes some time to learn all the commands but eventually you just forget about it and it becomes automatic.
There are other ways of navigating next besides just counting characters/words/lines as well (text objects and the like).
Vim does have a big learning curve. If you don't want to invest in it, that's perfectly fine.
For browsing/reading code, I don't see how vim can be much more efficient than a properly configure IDE that support crtl+click, the back and forward mouse buttons and a command of the keyboard shortcut.
:set rnu
:set nu
FWIW I would very rarely if ever use '5dd'; to me that is spelled 'd4j'. ':set rnu' obviously influences this, since the last line to be copied is labeled '4'.
Undo is 'u' and, yeah, you probably need to know that one before starting. Even after over 15 years using vim I still make tons of mistakes and change my mind, and a fairly robust undo system is crucial.
At first, err on the lower side, and 4dd. Over time, you'll start viewing things in chunks naturally, which probably only helps your code scanning ability, which is probably half the benefit of learning Vim. You get really good at looking at code like building blocks.
And undo is an easy one... Just type 'u'!
Like any skill or tool, it often seems not worth it before you know how to do it. But every time you learn a new skill (like you just learned undo!), it makes you more efficient for the rest of your life! How amazing is that?
...pause it before you watch it, look at the video description, and skip to 1m23s.
Grab the text from the video description in the editor of your choice, compare the before and after (heck, I'll probably go in and paste the "after/goal" so you don't even have to work at it).
Time yourself in your editor of choice to match the "goal" output.
Basically: `var $foo, $bar, $baz;` => `$obj = { "foo": $foo, "bar": $bar, "baz": $baz }`
...I randomly did it in about a minute, conveniently and subconsciously, and thought it was worth making a video about it (15 years ago...).
Nowadays I see easy fixups (eg: `gv`, maybe a macro...) that would have made it faster, but it's not about the speed, it's about the accuracy!
One of the most important "commandlets" of vim is the `.` command: "repeat last edit"
In the video when I perform(!) one "change comma into an arrow", I can `n` to "next" to the next anchor point (eg: a `,`) and repeat the edit(!)
Cleverly stringing together "edits" into interactive repetitions is like getting tetrises in Tetris (and about as easy, once you know to look for them).
vim is not an "editor", it's an interactive programming language for editing text:
`:g/def /norm 0fdf ywA #<c-r>"`
...find lines that match `def ...` (slightly sloppily), find the first 'd', find the following '<space>', yank the subsequent word (also could have yanked until a '('), and then append what was yanked as a comment.
Why?! Dunno. But like 30 keystrokes and I can edit the whole file to perform that operation, or any other arbitrary operation, and I can repeat that operation on any file I'd like.
It's "editing" in the sense that after a certain point you don't think about it, you just do it, and the text transformation isn't polluted by inaccuracies, as "advanced vim" encourages you to repeat, replace, define as opposed to "type".
Nowadays with LLM-autocomplete, and the temptation of "whole-git-repo" refactorings like: "change all my uses of list comprehensions to for loops, and use generators, but only for api responses that come from a particular domain" ... yeah, vim feels pretty baroque.
...but when you actually need to do some editing to fix up the mess that was made by the LLM, come talk to me. ;-)
Select the $, Ctrl+D to select the other ones, then select and copy the identifiers. Took me 28 seconds in total.
select $, cmd-d, "enter" (to get them all on newlines), then "$" to replace the lost "$", shift arrows/end to capture "everything", arrow/space over and "cmd-v" for paste, and then I got stuck. (can't "easily" line up the raggedly-pasted items with the multiple cursors and all the cursors seem to "float" weirdly after the paste)
...surely someone more experienced with sublime would know how to "get out of the mess", but I'm more experienced with vim.
I'm wholly not expecting to change your opinion on preferred editor, just sharing a little of the details the make the difference!
In Sublime Text there was an addon that did that. I assume something similar exists for VS Code.
To align the items manually I would Tab (or Space) as much as necessary so that each item has enough space for the alignment. I would then use the mouse to create multiple cursors in the same column. In VS Code it's drag MMB, in Sublime it's Ctrl+LMB or sth. Then Ctrl+Shift+Arrow_Right, Ctrl+Shift+Arrow_Left to select the spaces up until the (misaligned) beginnings of the words, then hit Delete.
I thought Vim could be efficient because if you just learn all these codes you can instantly cut 5 lines of code 5dd. But in practice I can't count so I cut the wrong number of lines, then I have to look up how to undo because obviously Ctrl+Z doesn't work, and the end result pretty much every time is that I'd be more efficient with VS Code or even Notepad than with Vim.
I just can't see where this "efficiency" is supposed to be at all.
If you tell me I'm supposed to spend 4 weeks reading VimTutor to gain efficiency in Vim, I could probably become more efficient faster in VS Code by learning all of its keyboard shortcuts. Btw Ctrl+/ comments the current line, but I always just press home // because that feels faster. It works with multiple lines, but I just use Alt+Down key in that case to create multiple cursors.