There's too many little things to mention, they do all add up to be quite significant in the course of programming.
Here's a tiny sample of some stuff I use constantly:
Move cursor forward word at a time: w ignoring punctuation: W reverse: b B
Move cursor to next occurrence of character Z: fZ reverse: FZ
Delete forward to next occurrence of character Z: dfZ reverse: dFZ
Change forward to next occurrence of character Z: cfZ reverse: cFZ (like delete but leaves in insert mode afterwards)
Repeat latest edit from current cursor position: .
A lot of the vi commands are composable, as illustrated to some extent above.
To search for say the next line starting with void: /^void
To delete from the current line up to the next line starting with void: d/^void
Note the similarity to dfZ/fZ from above, it's not 100% consistent but most times you can take a chance composing things as you'd expect and things work correctly.
There are far more sophisticated things too of course, but I'm not writing a vim tutorial in an HN comment.
You can do things like rename a function while rearranging its arguments either file-wide, or on a number of lines, or on an interactively selected visual region, or a section selected similar to d/^void... I presume other editors have such capabilities, but I'm most familiar with vim. In vim the actual renaming and rearranging is done using a regular expression containing backreferences:
You may constrain that to a subset of lines a variety of ways, and on top of that can suffix a 'c' on the end of the substitution regexp to make it conditional and you'll get a chance to interactively yay/nay the substitution at every match in the considered lines. The conditional suffix is a godsend as it lets you be fast and sloppy with your regexps and just skip the false positives.
Honestly, I can do almost all of these things with any standard editor as well, with standard shortcuts.
The ones I can't do directly, I can do via Search/Replace
functionality that is also standard in most modern editors.
Your example about refactoring a function by using text editing capabilities is actually pretty bad unless you mean Vim can actually parse your programming language and perform the refactoring over all your code-base (not just a single file), like any IDE will do.
This list you gave me just convinced me I don't need Vim.
Here's the real question - So you are convinced you don't need Vim, right? Why are you on this thread?
No one's saying vim is superior. However, you need to have an open mind to understand the alternatives.
It's not like Vim is a paid product and by you not using it, Vim is going to die out soon or anything.
If you dont' like it, great? You are happy with the alternative, great. You seem like you just want to deliberately start an argument and then prove you are right, but why?
I am in this thread because this is not a thread about how Vim is great, it's a thread about how Vim became popular, which I honestly don't understand in a day and age where modes are completely unnecessary. I see lots of happy Vim users telling the rest of us how they are so happy with Vim and they can't understand how anyone can do anything without it... so I thought I should point out I feel extremely productive on any non-mode text editor (all my shortcuts work even in this HN editor, on a browser, in Word, basically anywhere except old editors like Vim). Been programming for nearly 2 decades now and even when I started, I thought Vim was a tool from a time when we didn't have Ctrl and Arrow keys and we already had better alternatives.
At this point, I feel like "I use Vim" is like "BTW I use Arch", said usually with an air of superiority as if choosing "the hard way" was somehow smart.
which I honestly don't understand in a day and age where modes are completely unnecessary.
Modes are everywhere. My microwave has a defrost mode. Cars have reverse mode. Pill bottles have modes where the bottle has to be held differently to open it.
Modelessness isn't all it's cracked up to be.
I’ve used many editors on the Mac—BBEdit, SubEthaEdit, Chocolate, TextMate, TextWrangler and a few more obscure ones.
I switched to Vim and haven't looked back nearly 10 years ago because the "modeless" editors had limitations and issues I didn't like.
I used Emacs when I worked at MIT because that's what everyone used, but it never took for me when I had to use Unix.
What the author didn't mention is that when Ruby on Rails was the new hotness, so many of the leaders in that movement were Mac users, on TextMate. But when TextMate went into limbo, and then eventually died, that tribe needed a new editor and they essentially all moved to Vim.
Many of the early Rails videos were done on Vim; they were quite influential.
I wanted an editor I wouldn't outgrow in a few months and Vim fit the bill nicely.
And to this day, I feel like I'm pretty proficient with Vim but I also know I'm using like 10-15% of what Vim can do and it's nice to know all that capability is there for when I need it.
So if I understand you correctly you're angry that people choose to work in a way that you think is unnecessary and that they're just doing it to show off.
I can't speak for other vim users but I think it's pretty obvious to us how other users work without vim and we know you can be productive without it.
Personally I make a point of not telling people to learn vim but equally I think, for example, not having a shortcut to repeat a complex visual selection is a pain.
I never feel the need to enter a thread about IDEs and point out this missing feature (especially if it's a program I don't actually know well and that might not be the case).
However I often see people that don't know vim well make statements like "vim can't do x" without actually checking if that's true.
Then we look "superior" when we point out how to do it in vim.
It's hard to win because your argument sounds like an emotional one.
To win what? This is not a contest or even a debate where one point of view may prevail... we're just expressing our opinions about Vim and its alternatives here. Obviously, if you like Vim, great! But it seems to me you're the emotional one if you find it necessary to question anyone pointing out they believe Vim is not a good tool at all (it promotes modals, which should have died as soon as they became unnecessary due to hardware improvements as they are objectively harder to use) and wondering why it's still somewhat popular.
I use vim as a boring config editor in terminals. I don't think it's the best editor by a long shot and even something as basic as Atom is more productive for code editing for me.
The idea of customizing your vim setup for maximum productivity doesn't appeal to me. It always ended up in a mess and over ssh it's pointless.
So I am a fan of vim and have used it on and off for 15 years at this point. I generally use IDEs or VSCode these days instead for writing code. Here's my take.
I think the popularity of learning vim might be similar to what jiggawatts mentions as the 'perception of speed', especially for tools in the UNIX world, as well as being 'the hard way' like you mention. But I think there is value in learning how to use vim. I see the advantages of learning vim are programming language agnostic. Vim is focused around words and text, treating them as objects, and creating a mental map of keystrokes to modify those objects. I think it's somewhat analogous to typists that hunt-and-peck vs touch typists. Opens up a lot of productivity, but it's definitely not needed to be a writer.
I agree vim has many limitations. It has a not so great language for scripting, no out of the box setup for stuff like refactoring or renaming symbols in your codebase, GUI feels like a second class citizen (IMO, compared to the terminal version). In a lot of ways, it might not hold a candle to the likes of VSCode, Atom, Visual Studio, XCode, IntelliJ, Eclipse, etc.
The nice thing is that you could add a vim-like plugin to any of those IDEs/editors to match the spirit of vim, at least in terms of navigation. It's not like you need to stay in vim to reap the benefits of the mental model.
I think that's where a lot of the power and appeal of vim is. Vim is still drawing a new generation of programmers, artists, and hobbyists to learn this strange text editor, with its unique but powerful way of interacting with text.
The parent described only a fraction of what vim can do. The notion of text objects and combining them with plugins makes vim much more powerful. Even without plugins mastering vim makes writing code quite natural.
vscode has regex find replace, but I don’t use it very often. It does show every match highlighted in the current file while entering the find value, which is nice.
It does the same for multi files if needed and gives a nice preview of every change.
Word navigation I use a great deal (especially with multi-cursor editing). Ctrl+left/right jumps words, home, end to begin end of line.
Ctrl+f Z Enter would go to next Z value. (Which I don’t use, because I don’t think in partial words much, but rather jump to mouse if I need to navigate far)
That’s probably where I could gain in using that instead of going to the mouse every time.
Ctrl+arrow is almost as bad as going to the mouse. The thing with vim is you rarely have to leave the home row.
Some other random things I use constantly (I am not the person you're replying to):
C — replace to the end of the line
xp — swap two characters (which I have to use more frequently than I'm willing to admit.)
ci( — replace everything in brackets (like the arguments of a function, this also works with " or ' for strings, { for blocks of code, and so on). The cursor doesn't have to be inside the brackets, it'll jump to the nearest match.
:earlier 10m — time traveling, which comes in handy between commits or with config files, especially if you configure vim to write persistent change history. What did this file look like a month ago? Oh yeah, :earlier 30d
. — repeat the previous command (this is much bigger than it sounds, as it allows you to repeat the same complex manipulation on different data in situations where you can't use multi-cursor, but which don't warrant building a whole macro.)
A ton of custom filetype- and mode-dependent <leader>-based bindings (which is the spacebar in my case). space-space to jump to definition, space-f to reformat the file, that sort of stuff. This can probably be done in vscode.
If you're really interested, there are tons of vim videos on youtube made by real vim pros. I am very far from being one. The best for me are live coding sessions where vim usage is demonstrated by doing the real work, not on some toy examples.
> :earlier 10m — time traveling, which comes in handy between commits or with config files, especially if you configure vim to write persistent change history. What did this file look like a month ago? Oh yeah, :earlier 30d
Another trick to my bag, that's why I absolutely love these threads about Vim.
On a Mac at least, ctrl+n/p/b/f/a/e all navigate text without reaching for the arrows, with the added benefit they work in every application. I quit vim because I prefer using a smaller but universal set of navigation that works everywhere from Xcode to VS code to the terminal or typing in Chrome.
Ctrl-arrows is not the same thing as vim’s wordwise movement. If you need to go 5 words forward, it’s 5w ; if you want to capitalize the next 3 words, gU3w ; the point is composability, not a single operation. Same goes for f.
I guess I, and maybe other non-vim users, just don't see much use in the composability. From many examples I've seen in this thread, the only one I found truly interesting was the branching undo feature.
For most features, the advantage seems very small, as the use-case is so rare, or it's not the limiting factor anyways.
But this is very limited to my experience. I am pretty sure, if I already knew those things, I would value that investment the same way the vim users do in the vim threads. But for now, it seems to me, that the investment is not worth the payoff and I am better off learning something else.
I use the vim plugin inside of VSCode and it's perfect for me. I would never go back to just VIM, or just an IDE. but my best use case for vim modes is stuff like: [c]hange [i]nside ["], where wherever your cursor inside inside of a "string", you can just press ci" and can immediately start typing a new string to fill it. And then this same thing can be changed to ci{ to change everything in {} to change a function, or ci( to change a function's paramaters, etc.
Then theres stuff like [c]hange un[t]ill [x], to change everything up to a certain character.
or [y]ank [i]nside ["], to 'yank' (copy) the text inside of a string and be able to paste it immediately anywhere I want to. It's verbs and sentences that you're writing in VIM modes.
Do modern editors have these kinds of keyboard shortcuts?
In general I think vim users are extremely bad at explaining why vim modes are so good, as I never use 5w. Am I really going to count how many words ahead I have to go? No, i'll just press [f]ind char to the word I have to go to.
The biggest thing about vim is that it doesn't make you more efficient or faster, it just eliminates the time you have to think about how to edit text once you internalize it, which I know doesn't sound likely because the keybindings are so strange. But know that I've learned it, i genuinely don't think about it, and every time I'm not in VIM and have to move my mouse and click on a character I feel like I lose my train of thought of where I was in the code
Actually I never wondered if there were shortcuts for those, so your response prompted me to check the keymap of m PyCharm. There definetly are many extended ones, but doesn't seem to cover all of that and are not as composeable.
> But know that I've learned it, i genuinely don't think about it, and every time I'm not in VIM and have to move my mouse and click on a character I feel like I lose my train of thought of where I was in the code
I believe that, so please believe me when I tell you that I just have navigation with the mouse and other shortcuts internalised for many things. I'm not really actively thinking about it either.
Thanks for taking the time to share your thoughts!
> I believe that, so please believe me when I tell you that I just have navigation with the mouse and other shortcuts internalised for many things.
Definitely! I just want to provide an actual reason for why VIM is great as people who are very into it are the worst at telling you why it's good.
It's usually, "well if you spend 3 months tinkering with configurations and plugins, you can basically have most of the features an IDE has out-of-the-box!" which misses the entire damn point of vim.
Also it's great because if you're ever ssh'ing into servers, you can be confident that you can be close to as productive editing files there as you are in your IDE, which I find very re-assuring. But as it is right now, I don't see a reason why anyone should switch to vim unless they enjoy the act of learning it and want to get some of the cool composability features, which are just fun to use and learn
> Delete forward to next occurrence of character Z
How often do you really do things like this though? It seems like, sure you can do weird obscure things quicker in Vim, but only if you happen to remember how do to the weird obscure things, and it's only useful in weird obscure situations.
For 99% of tasks the built-in VSCode stuff does the job for me. Ctrl-D especially.
> How often do you really do things like this though?
All the time. Some examples:
* ct, : "change up to comma", useful for replacing a function argument.
* ya" : "yank around '"'", copy the string literal the cursor is currently inside.
* ci( : "change inside '('", useful for changing the condition in an "if" statement.
* da{ : "delete (i.e. cut) '{'-delimited block", useful when changing the structure of if/else blocks.
I agree that these commands may sound obscure, and many Vim users use the program for a long time without using them (I certainly did). But when you start using them, you find that these composable editing commands correspond really well to many of the logical editing actions you perform.
I don't use vim, but this feature seems mostly useful for deleting things within marking characters, such as " and ', which I do surprisingly often. (But not often enough to learn a shortcut to do it)
Not that specific example, but you'd really be surprised by how useful some of these things are. For example you can do a `di[` to delete everything inside an array. Or `ci"` to replace everything inside a string.
Here's a tiny sample of some stuff I use constantly:
Move cursor forward word at a time: w ignoring punctuation: W reverse: b B
Move cursor to next occurrence of character Z: fZ reverse: FZ
Delete forward to next occurrence of character Z: dfZ reverse: dFZ
Change forward to next occurrence of character Z: cfZ reverse: cFZ (like delete but leaves in insert mode afterwards)
Repeat latest edit from current cursor position: .
A lot of the vi commands are composable, as illustrated to some extent above.
To search for say the next line starting with void: /^void
To delete from the current line up to the next line starting with void: d/^void
Note the similarity to dfZ/fZ from above, it's not 100% consistent but most times you can take a chance composing things as you'd expect and things work correctly.
There are far more sophisticated things too of course, but I'm not writing a vim tutorial in an HN comment.
You can do things like rename a function while rearranging its arguments either file-wide, or on a number of lines, or on an interactively selected visual region, or a section selected similar to d/^void... I presume other editors have such capabilities, but I'm most familiar with vim. In vim the actual renaming and rearranging is done using a regular expression containing backreferences:
You may constrain that to a subset of lines a variety of ways, and on top of that can suffix a 'c' on the end of the substitution regexp to make it conditional and you'll get a chance to interactively yay/nay the substitution at every match in the considered lines. The conditional suffix is a godsend as it lets you be fast and sloppy with your regexps and just skip the false positives.