Does anyone have a good video comparing vim speed coding vs vscode using built in editor features?
I’ve been using vscode for years and the YouTube videos that demo vim features are shallow (like how to enter a blank line - really?). I can do the same thing I have seen in vim videos without memorizing a bunch of strange key bindings all while being able to edit code instantly without changing modes.
I would love to see a fair comparison between someone using vim at 100% and someone using vscode at 100%.
Of course some vscode shortcuts might not be fair (like F12 to jump to definition, F2 to rename every usage, etc.)
But even in raw editing:
With vscode, I can do multi-line editing, I can navigate quickly, jump to specific words, etc all very fast.
If there is no video like this, would anyone be interested in a race?
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.
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
Ya, basically go up, grab number, go down, paste number, increment number, go down, repeat 50 times. Needed for generating xaml that had row and column #s from the csv, interestingly excel could gen the code too relatively quickly.
copy 10 lines from the current position into buffer q, go to the start of function jnk, copy 5 lines into buffer w, jump to line 10, paste contents of q, contents of w, and contents of q sequentially one after the other:
"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.
I have a plug-in installed in vim and vscode (and ilellij) that provide me with relative line numbers in addition to absolute line numbers. So, the current active line might display "353" in the gutters for the 353rd line. Both the line above and below are 1. The next lines above and below are 2. And so on.
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 :)
I find it interesting how we use vim so differently. I'd never type "10yy", I'd use "y9j". I never use "10G", I use ":10<CR>" (<CR> = enter for those not familiar). Similarly, "0G" is "gg" for me. Call me a notepad user, but that whole second snippet for me would be "ggV19j>" followed by "." until things lined up correctly. Similarly, the third would have been "V14j:s/a1/A1/g".
Nit pick: "q selects register q. A buffer is a different thing.
If the language uses curly braces to define blocks, it's easier: ciB. Parentheses are easy as well: cib.
Otherwise, I'm not sure there's a good solution currently. You can substitute by indentation with a plugin (https://github.com/kana/vim-textobj-indent/blob/master/doc/t...). For Lua, I usually do c/end<enter>.
I believe this is an area where treesitter can help, so I'm looking forward to Neovim's integration.
Highlighting the initial { of a function and then typing 'va}' ('v' for entering visual mode, and 'a}' moves to the matching close brace. Similar commands work the [], (), and <> pairs) selects the entire function body. From there, a regular s command will operate on the entire selected text.
There are things that vim does better. There are things that VS Code does better. There are things that Visual Studio does better. You can memorize all sorts of things about your particular editor of choice and you will be more efficient and effective in that editor.
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.
Not if you use Emacs/evil. Tramp invalidates most of the "well, vim is available on all my remote servers, whereas Emacs never is". I just remote into a server from within Emacs.
Evil is also the best and most complete vim experience outside of vim.
For your use case there are a lot of ways to do that in Vim without using the multi cursor, here[0] is one thing I just recorded to show you a glimpse of what's possible with just a search and replace: I just find a pattern and replace it with a part of the same pattern.
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.
There's a couple of ways you could tackle editing that depending on what your json looks like.
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:
Jump to definition and rename every usage are really handled by the language server. Vim supports language servers quite well. I do both those commands in vim all the time. And vim complements them with (book)marks, return to last edit, etc.
Vim can jump to definitions and stuff too. It integrates with ctags. It can also do code completion and everything else. I have it bound to clang-format with ctrl-k.
Heard good things about it, but I'm on an endeavour to learn how to do things with Vanilla Vim first to avoid abusing my use of plug ins for things Vim can handle gracefully ootb.
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.
I'm with you with avoiding too many plugins. But LSP is not just another plugin, it's the standard for languages to implement IDE support. I find it hard to justify not using it if you're doing serious software development (depending on the language of course).
Thanks for the kind words on autojump :) I'm no longer involved with the project, but I feel the general idea is still relevant.
Between the awkward file navigation and the feeling of building my own editor from the ground up, I just never found it worthwhile to fully commit to Vim. So I work in VSCode in my day job.
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.
> I can do the same thing I have seen in vim videos without memorizing a bunch of strange key bindings
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.
One vim hack I like is multi-line macro application. It's a good fallback in case, as I often forget the syntax for certain things. To facilitate this, I've remapped ctrl-space in visual line mode to apply my `q` macro to every selected line.
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.
I've found keyboard-only vim is much slower than a mouse for editing papers, because the edits are often random-access and vim isn't great at that. You also can't use SyncTeX (which is amazing) without a mouse.
There's no point in comparing them, in my opinion. VS Code is a tool for programming; I would call it an IDE but I 'm not very familiar with the app. Vim is still "just an editor". You can still use it for programming (not just coding bash scripts), but that's making your life harder than it needs to be.
In my experience the amazing text editing features of vim are only very rarely useful in a software developer's work. I feel the same about multiline editing though.
And Vim has amazing text editing features, but severely lacking code editing features.
I’ve been using vscode for years and the YouTube videos that demo vim features are shallow (like how to enter a blank line - really?). I can do the same thing I have seen in vim videos without memorizing a bunch of strange key bindings all while being able to edit code instantly without changing modes.
I would love to see a fair comparison between someone using vim at 100% and someone using vscode at 100%.
Of course some vscode shortcuts might not be fair (like F12 to jump to definition, F2 to rename every usage, etc.)
But even in raw editing:
With vscode, I can do multi-line editing, I can navigate quickly, jump to specific words, etc all very fast.
If there is no video like this, would anyone be interested in a race?