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:

  s/old_func(\([^,]*\), \([^)]*\))/new_func(\2, \1)/

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.

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?

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.

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.

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.

So if you undo something a few steps and try something different but decide you want to go back you can’t... but you can in vim with g+ and g-

If you add the Gundo plugin you can visualise this as a tree of diffs in a side window.

I’m sure that’s been added to IDEs as a plugin but in vim it’s standard.

It also persists undo state to disc if you want so if you return to a file on another day it’s still all there.

You select some text, either via keyboard or mouse. You realise you’ve missed a bit at the start of your selection.

In vim without having to start over you press o and it moves your cursor the other end of the selection and you can now extend it.

Deselect accidentally and want the selection again? Press gv.

I’m sure these little features are available in other editors but not always or not always by default.

WTF is a standard editor and standard shortcuts? Would that be ISO or ANSI?

Isn’t that just another way of saying I can’t do these things but don’t care? The Blub argument effectively.

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.

As a 30-year Vi/Vim/NeoVim user, I can confidently say, "No, you can't."

https://www.youtube.com/watch?v=wlR5gYd6um0

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.

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.

Another trick to my bag, that's why I absolutely love these threads about Vim.

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.

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

> 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!

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

Thank you for that, I value it! It seems I was unneccessarily defensive!

> 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

That is a nice point.

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.

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.

https://www.youtube.com/watch?v=UDGG3hK4Bg8

Its a simplified version of a problem from work a while ago where we had to generate ui from lots of csv files. The last dev on it was taking weeks, but with vim I was able to come in and finish the boilerplate instantly. (We were commited to non-dynamic ui at that point, I think I made the right play especially with how we ended up using it).

Vim is, in my opinion, inferior to an ide or a good text editor, but if you have it as a plugin you get the best of both worlds and vim suddenly can do... basically anything you can think of. Like here's putting a breakpoint on every line in a file

https://imgur.com/SFhlEr7

The best part of vim in an ide is when you're pair programming and you do something fancy, and your friend says "Wait, go back, howd you do that??"

The way I would do that in vscode would be with a multi-edit, but it would get iffy at that many lines.

I‘ll record a video doing the same for comparison tomorrow.

This makes me wish there was a site for recording challenges like this where developers could race using their favorite tools.

Vim vs VScode would be an amazing way to learn tips from experts on both sides.

"q10yy /jnk "w5yy 10G "qp "wp "qp

now, go to the start of the document and indent the next 20 lines by 10 spaces:

0G .,+20s:^: :

ok great, now find JUNK and replace 'a1' with 'A1' in the 15 lines that follow:

/JUNK .,+15s/a1/A1/g

probably not as efficient for multi-file refactoring, but for raw 'drag race' style text munging, everything is there, loaded in muscle memory, and under the home row of your keyboard so you don't have to lift your hands at all.

Just thinking out loud how to do that in vscode for comparison:

- I don’t think repeating actions a specific number of times makes sense in most use cases. Counting 10 lines would take longer than doing shift up/down n times (which would be exact with feedback) to select the desired lines.

- Multiple Copy Paste buffers sounds interesting, I might look up a vscode extension for that. (Had a copy paste queue in Visual Studio but it would break sometimes and would lose something important).

- go to start of function jnk, there are many ways to do that in vscode. Ctrl+f jnk enter would be one.

- Goto start of document is Ctrl+Home

- Indent 20 lines by 10 spaces, could do Alt+PageDown, then up/down to get to the right place (without counting or caring that it is exactly 20 lines), then with multi-line insertions could space,tab, etc.

That operation would probably justify mouse usage though, in which you simply hold alt, drag ~20 columns/~10 cells and hit space - which itself would be faster than counting 20 lines.

- find junk: ctrl+f junk enter

- select 15 lines (shift+page down,up/down to adjust) I can preview I have selected the correct area, other possibilities to select current function, etc.

- Ctrl+h to replace, a1 tab A1 Alt+L Enter

- of course in most cases, I am renaming a symbol, so “F2 A 1 Enter“ would do

I think the reality is that counts are not known before hand, so being able to increment/decrement with visual feedback is perhaps faster than a miscount, but I’d have to see it to know.

Anyway, thanks for the detailed examples! I can certainly see how it would be powerful if committed to muscle memory, but even with vscode there are many shortcuts I don’t use because of formed habits.

There is never any "counting lines". If I need line's number, I can do a quick addition/substraction in my head or j/k $offset to see the other line's absolute number.

I can do line-based operations a lot faster than shift-tapping or click-dragging, with exact precision because my editor has been customized to provide the data I need. Eventually you get pretty good at estimating line numbers and character columns too.

for line counting - indeed a good point and clearly required for the examples -

After time, eyballing this becomes a skill. For things that fit on a screen (~50 lines or so, give or take) I'm usually correct 1st time or within a few lines. I can check quickly by moving the cursor (20j to go down 20, 20k to go back, repeat if necessary to get the line count)

also as others have pointed out, I might not be doing the best/optimal thing for some of these, just some examples of how I do things that popped in my head :)

Vim get round that by providing the option of relative line numbers to the current line.

That’s accessed via

  :set relativenumber

Nit pick: "q selects register q. A buffer is a different thing.

The real scenario is usually to replace, for example, in a function block. How do you do that? Counting function lines seems like a non-starter.

I believe this is an area where treesitter can help, so I'm looking forward to Neovim's integration.

Of course Vim can replace a function block easily and has been able to do so for decades.

For example, let’s say I have a json object with variety of field names, one per line and I want to remove the quotes.

With vscode, I can alt select all lines, Home Ctrl+right del cntl+right del.

The trick is the field names are different length, does vim have multi-edit with the ability to navigate relative to each insertion point?

Edit: Here is a good video example (https://youtu.be/iomWEDMBlcE)

Can vim do something like that?

If I wanted to cherry pick examples of what vim does better, I could start all of them with, "first ssh into a random server."

What makes vim great is that it has a tremendous number of features and is available nearly everywhere. Can VS Code do that?

If you’re on a new machine, you can grab your dotfile repo from wherever you keep it—like GitHub for example—and you’ve got your complete config, since there just text files. Takes 5 minutes.

But even plain vanilla Vim is more than enough for many tasks on a new Unix/Linux box.

Evil is also the best and most complete vim experience outside of vim.

> Here is a good video example (https://youtu.be/iomWEDMBlcE)

Again, you can do everything here without using multicursors, just record a macro for one line and repeat with a count and you're set.

Now if you absolutely want the multicursor feature, there are more than one plugin[1][2] for that, but I never felt the urge to use multiple cursors in Vim.

0: https://youtu.be/YR7rRC-vwj4

1: https://github.com/terryma/vim-multiple-cursors

2: https://github.com/paradigm/vim-multicursor

For example you could use the visual block mode (ctrl-v) and highlight to the end of the line using $ and then use A to edit the end of every line at the same time. That works with lines of different length.

Or you could use a regex inside of a block selection.

Or there's a multi-cursor plugin available for the same approach as you're currently using in VSCode:

https://github.com/terryma/vim-multiple-cursors

Vim Golf is an excellent resource for seeing how to efficiently edit things in Vim: https://www.vimgolf.com/

I personally would rather use :s (search-replace) for that. Regexp is your friend.

Now you're the creator of autojump, I just want to say your software is definitely a time saver, especially with this https://github.com/fdw/ranger-autojump, keep up with the great work.

Thanks for the kind words on autojump :) I'm no longer involved with the project, but I feel the general idea is still relevant.

What I did take from those efforts, though, was Vim's text navigation key bindings. They are a joy to use and most text editors have some sort of emulator for them. The beauty is in the chording, almost all of which maps to easily remembered mnemonics. Delete everything between quotes? Use di". Change curly brackets to square? Change surround, or cs{[. Once you've gotten used to switching between move and edit modes, you can layer these in bit by bit. At a certain point it becomes second nature and you do feel like you can edit code at the speed of thought. It's a powerful feeling.

you totally can! I could talk for a while about customization and ctags to address some other points you made but at the end of the day its a text editor, vim and vscode are both text editors. it sounds like you really like using vscode so you should stick with it, I really love vim and it works really well for me, and my boss loves using a near vanilla sublimetext 2 install. programming will never be about typing and editing speed but being comfortable with your development environment and hopefully even enjoying it is very important.

As an example, say I need to add a comma to a bunch of lines. I will record the macro on that line appending a comma to the end, visually select all of the other lines to copy the macro on, and then jam my hotkey to apply the macro.

It's often much quicker than reaching for a regex for short segments of code.

    V<count>j (3)
    :'<,'>norm A, (8 - The angular brackets are automatically added by vim)

    qq (2)
    A,<ESC> (3)
    q (1)
    V<count>j (3)
    <CTRL><Space> (2)

Why, oh WHY, do those #?@! nutheads use vi? http://www.viemu.com/a-why-vi-vim.html

It even supports using a mouse over ssh.

I don’t know SyncTex so can’t comment on that.

Why would one be suitable for programming but not the other?

It just comes down to UI preference and whether you want to configure things yourself or not.

Both support plugins, so the possibilities are basically endless