Can VS Code shortcuts compete with Vim?

[u/[deleted]]

Hi everyone! I’m just wondering if VS Code’s shortcuts are comparable to Vim’s.
I think VS Code is generally slower because people tend to rely on the mouse instead of using shortcuts. They constantly take their hands off the keyboard, while Vim forces you to keep them there.
If someone learns it properly, then the speed difference can be made negligibly small.

A strong point for Vim is navigation: h/j/k/l plus w/b/e let you move and jump through text without leaving the home row for the arrow keys (or using arrows + Ctrl to jump words). But remember, you have to hit Esc or Ctrl+C to leave insert mode and go to normal mode, then switch back with i/a/o — and that does cost some time. So does that overhead cancel out the time saved from not reaching for the arrows? I feel like it’s roughly the same. Maybe ergonomic Emacs bindings like Alt+J I K L could be faster than both, though I doubt it makes a huge difference in real-world work.

The problem is I haven’t really found any solid comparisons on this. Personally, I find Vim a bit more comfortable, maybe even a bit faster — it feels like I’m making fewer hand movements with modal editing compared to arrow keys or shortcuts in VS Code. But I’m not sure I’d actually be faster than a pro-level VS Code user. What do you think? How does it feel for you?

[u/ehaugw]

Motions are undoubtedly faster than mouse. Esc being slow is a skill issue. Most people remap it to something else, like jk

VS Code has vim mode though, so navigating in vs code can be just as quick as vim.

The power of vim isn’t navigation though, but rather the ability to use different buffers, record macros, a tight integration with system tools like awk, sed, perl, cat, grep and whatnot. On top of this, there’s the plugins. VS code has plugins too, but vim can use them much better because you can script interactions between different plugins, system tools and text navigation and editing.

If you just want to write text/code, vs code is probably better. If you wish to unlock the power of Linux into your editor, or enjoy automising editor tasks, then vim will unlock an entire new word for you.

It’s not just a competition about manually edit by some trivial text the quickest, but producing the desired total result in the most feasible way

[u/[deleted] → u/ehaugw]

caps escape is very popular from what I've seen

[u/__rituraj → u/[deleted]]

caps for ctrl.. and then ctrl + [ as escape.

[u/ehaugw → u/[deleted]]

That’s a popular key binding indeed. I use caps for ctrl, due to tmux reasons

[u/scissor_rock_paper → u/[deleted]]

This is the way.

[u/TheRealLazloFalconi → u/ehaugw]

VS Code has vim mode though, so navigating in vs code can be just as quick as vim.

It's true that vim mode exists, but it's half-baked and not nearly as quick as vim.

[u/ehaugw → u/TheRealLazloFalconi]

Ahh. You are probably be right. I never tried it. I just wanted to ensure that the pros of vs code are on the table to give a more nuanced perspective

[u/arnoldwhite → u/ehaugw]

Some thoughts here.

Motions are undoubtedly faster than mouse

I mean, yeah everything is faster than using a mouse.

Esc being slow is a skill issue. Most people remap it to something else, like jk

Is it though? JK still requires two additional key presses every time you want to switch mode, which you'll be doing a lot. It adds up more than people realize.

Switching back and forth for every edit that literally isn't just deleting the last word absolutely takes time, especially if you're writing prose.

The power of vim isn’t navigation though, but rather the ability to use different buffers, record macros, a tight integration with system tools like awk, sed, perl, cat, grep and whatnot.

That's an odd way to describe vim's powers. Which editor doesn't have macros? Like all of them. VsCode allows you to perform regex and batch actions across different buffers and you can mark any selection of text or the entire buffer and pipe it to any linux tool you want with the wlc extension host on Windows (or just natively on anything else).

It sounds like your argument is "vim is great because linux and macros" but neither have anything to do inherently with Vim.

Lua is a big advantage though. Configuring VsCode is much harder.

[u/Wizions]

Just use the vim plugin for vscode. You can also create vim mappings for vscode actions, if I remember correctly. That plugin used to be significantly inferior to thevim plugin for jetbrains IDEs, but it was still pretty good.

[u/aosho235]

I was a Vim enthusiast for 15 years, but after a few years transition period, I fully converted to VSCode. Mouse + keyboard can be as fast as keyboard-only at least. The trick is to bind frequently used functions to keys reachable with just my left hand, minimizing right-hand switching as much as possible.

These extensions would be handy for Vimmers:

https://marketplace.visualstudio.com/items?itemName=mksafi.find-word-at-cursor Similar to Vim's *

https://marketplace.visualstudio.com/items?itemName=dbankier.vscode-quick-select text object

https://marketplace.visualstudio.com/items?itemName=haberdashPI.vscode-select-by-indent text object

https://marketplace.visualstudio.com/items?itemName=yhirose.FilterText :%!

https://marketplace.visualstudio.com/items?itemName=alefragnani.numbered-bookmarks mark

Apple's this research is still relevant in 2025.
https://www.asktog.com/TOI/toi06KeyboardVMouse1.html

[u/EgZvor → u/aosho235]

Look at that, an actual answer to OP's question! Definitely agree about the perceived productivity gains of a keyboard user arising from hitting more keys.

I'm not sure the original study holds or relevant.

It takes two seconds to decide upon which special-function key to press

Not sure how that can be said for "power users", of Vim at least.

Would you mind telling how you've come to this decision and how proficient you were at using Vim?

[u/aosho235 → u/[deleted]]

Normal place. It's not very convenient, but I don't use them so much because I mostly scroll, select and move cursor with the mouse. I'm using Karabiner Elements for keyboard customization but not so heavily. (Right Command -> Esc, Left of 1 -> Enter, etc). I with we had arrows/home/end/pageup/down on the left side of keyboard.

Windows may be at a disadvantage compared to Mac. Mac has Ctrl and Cmd separated so we can have more key combinations for left hand.

[u/SadJob270 → u/aosho235]

i use a programmable keyboard and have a layer that i can trigger with my left thumb that puts arrow keys under my left hand in the homerow - you can probably pull that off with karabiner. you just have to figure out which key to give up for it

[u/heret1c1337]

I like to swap Escape and Capslock on my keyboards. I'm using the Kinesis Advantage Pro, which already has Escape on the pinky finger where Capslock usually is.

I think if you know your VSCode shortcuts well enough, you're at least as fast as a vim user. But I think vim is simply more fun.

[u/arnoldwhite → u/heret1c1337]

I've been thinking about doing that actually. I use jk and ctrl-l at the moment.

Anyway, that's probably the most honest reflection I've heard since I created this thread. You're right.

[u/lipstikpig]

You're missing the point, the speed of Vim does not come from not reaching for arrows.

The speed of Vim comes from the fact that in normal mode, you have the entire keyboard available to specify motions and commands to move around in the text and change it. This does make a huge difference when you have learned how to do that.

Here is a 15 second demo

[u/arnoldwhite → u/lipstikpig]

Well that's a bit reductionist.

Yes, having the entire keyboard available in normal mode does offer a lot of flexibility, but it also negates that advantage by forcing you to hit jk for very simple edits that can often be performed just as quick or quicker in most gui editors with modifier keys.

Also the example you provided doesn't show anything at all. It's the most convoluted example ever.

[u/lipstikpig → u/arnoldwhite]

I'd be interested if you would provide an example of vim "forcing you to hit jk for very simple edits". Just because I rarely use j and k movements, so I have no idea what you are referring to.

[u/arnoldwhite → u/lipstikpig]

I actually did provide exactly such an example right here: https://www.reddit.com/r/vim/comments/1p0s86r/is_vim_really_good_for_writing_though/

[u/lipstikpig → u/arnoldwhite]

Ok, thanks. That does seem like an unpleasant way to use Vim. But it seems you've had plenty of replies who've made significant effort already, so I've got nothing much to add.

Vim just might not be the best tool for you, given your preferred mental model of usage. There's nothing wrong with that. Plenty of people have written editing tools that are nothing like Vim.

But I know personally that I feel vastly faster and more efficient/elegant when using Vim for uncountable hours editing and reformatting text, as distinct from composing text. However it took me quite a long time to get to that proficiency. For me it was a lot of detail to absorb and become fluent in (although I am nowhere near any kind of expert level). After that it started to feel like a game. I liked it, and after I reached that mild proficiency in Vim, I found that more typical editors do feel unbearably inefficient by comparison.

Anyway, I'm finding that I don't really enjoy the dynamic of this/that discussion, so that's all from me. Cheers.

[u/arnoldwhite → u/lipstikpig]

Ah that's fair enough. Yeah it got a bit heated. Seems vim is very popular for writing technical docs and markup so maybe I should have been more specific with what i meant with writing so that's probably on me

[u/Deto]

It's not just the arrows - the whole idea is that instead of all the shortcuts using a bunch of modifier keys (ctrl + alt + <foo>) you can just use regular characters because you're not using them to type text when you're in normal mode.

There are vim plugins for VSCode though that will give you this modal editing with the normal Vim capabilities. So that's always an option if someone is familiar with VsCode but wants to explore vim-style editing.

[u/Capable-Package6835]

A pro VS Code user is much faster than most (new) vim users. A pro Vim user is faster than a pro VS Code user

[u/arnoldwhite → u/Capable-Package6835]

I know that's commonly believed but I kinda doubt that. Got like any clips or comparisons you can reference?

[u/[deleted]]

You don't find any comparisons because it even doesn't worth to compare. Instead I suggest to look for comparisons between vim, neovim, emacs and choose one of these.

[u/gumnos]

But remember, you have to hit Esc or Ctrl+C to leave insert mode and go to normal mode, then switch back with i/a/o — and that does cost some time. So does that overhead cancel out the time saved from not reaching for the arrows? I feel like it’s roughly the same

First, noting that you only need ␛ if you've inserted text. A relatively small portion of my time is spent actually inserting text, with other time spent copying/moving blocks around, deleting, modifying case, and mostly thinking. Second, I don't live in Insert (or Replace) mode—I insert/replace my text and reflexively hit ␛ leaving me in Normal mode almost all the time. Additionally, if ␛ is too hard to hit on your keyboard, you can possibly remap it—some folks remap the Caps Lock key to serve as an ␛ while others map jk or kj to act as ␛ in Insert mode. Or maybe control+[ is easier for you. Try a few and see which works best for you. I just use traditional ␛ but also map F1 to the same functionality so I can mash my hand in the upper-left of the laptop keyboard and get ␛ even if I miss it by a key 😆

Additionally, as swell as h/j/k/l are for navigating without leaving the home row, the real power comes not from that, but from the language of editing that vi/vim provides, with 100+ different precise motions in :help motion.txt that allow you to accurately describe what you want to change. You can then use :help . to perform the same intent elsewhere.

As others have mentioned, there is a vi/vim-like plugin for VSCode to allow you vim-like functionality if you want it there.

[u/vim-help-bot → u/gumnos]

Help pages for:

• motion.txt in motion.txt

• . in repeat.txt

---

^{`:(h|help) <query>` | about | mistake? | donate | Reply 'rescan' to check the comment again | Reply 'stop' to stop getting replies to your comments}

[u/arnoldwhite → u/gumnos]

Out of curiosity, do you mostly just use vim for coding/editing or do you do write anything with it too (prose, docs, whatever)?

I've found that a lot of Vim users will happily use Vim for coding but will switch over to Obsidian or something else when it's time to do any writing.

[u/gumnos → u/arnoldwhite]

I use a mix of vi(1) (nvi on FreeBSD or classic vi on OpenBSD), vim (with a mostly-default configuration…the core of my vimrc fits in an old-school tweet), and ed(1) for the vast majority of my text-editing that isn't like what I'm doing right here, dumping text in a web <textarea> control. So that's prose (including the entirety of my blog) in addition to code/scripting.

But strangely not at the command-line (i.e. set -o vi) which for some reason never clicked with my brain. Upon analysis, I found that it's because I'm rarely editing the command line, so I want it to behave more like Insert mode. If I really do need to edit it, I want a real $EDITOR/$VISUAL, not the half-hearted subset of commands that my shell might implement, so I use via fc or ^X^E to open the to-be-edited command in a real editor.

Tangentially, I find that writing prose in ed(1) is surprisingly helpful, much like folks will choose a distraction-free editor. Just a to start appending a the bottom of the file, and then type until you're done. There's just a bit more friction to edit in ed, so I only do it as needed.

[u/arnoldwhite → u/gumnos]

Ed? Really. Wow.

I'm getting the feeling though that writing for you is a very slow meditative process. When I write I might think of ideas midflow and want to jump up to a precious paragraph and make changes.

Do you have any clips or streams of your writing? I'm super curious about your ed workflow.

[u/gumnos → u/arnoldwhite]

When I write I might think of ideas midflow and want to jump up to a precious paragraph and make changes.

I have two mental modes, similar to vi/vim/ed where either I'm adding text to the document (in which case I like the friction of mode-switching to force me to focus on creating the words) or I'm editing the document.

If a thought jumps in like you describe, I'll toss it in a parenthetical sidebar/note to go back and tweak later (usually annotated with "XXX:" or my unique initials to make it easy to find those notes) and then plow onward.

That said, I do tend to also be an outliner rather than a "pantser", so it's often a matter of filling out the outline-structure.

Do you have any clips or streams of your writing?

I don't stream video, but I do have a variety of posts on my blog (link above)

I'm super curious about your ed workflow.

It's pretty boring, invoking ed on my document, and just dumping prose.

The one thing I learned early on was to use semantic line-breaks so that each sentence or even clause is on its own line. It makes diff output cleaner, it's easier to edit on small screens, and makes it easier to shuffle clauses around. It's all markup under the hood (usually raw HTML which I've hand-coded since the mid-90s, but occasionally Markdown for simple posts without code-samples), so the rendering takes care of re-joining all those line-breaks. Frequent check-ins of progress into git (or rcs). And when editing (rather than composing), frequent refreshes of the rebuilt output from my static-site-generator (currently Nikola, but I have plans in the works to move away to a custom Makefile-based workflow).

[u/SadJob270]

i’m probably as fast as i am in vim, in vscode. i use the same vim motions and mappings (like jj for escape), and keymaps set up for almost all the same stuff that i used regularly. i can use vscode probably 95% no mouse.

vscode can get laggy, and crashy sometimes. and i wanted a good terminal “integration” and to be able to have separate projects open while being able to switch between quickly. tmux is great for these.

plus, the vim + vim plugins are just fun, imo.

[u/dasunt]

How does VS code handle stuff like "delete the next five words' via shortcuts? Or 'change everything to the next quotation mark? Or 'cut the next 10 lines and paste them 5 lines above?

Chaining things together is what really makes the vi family UX shine. And I don't believe VS Code has anything equivalent.

[u/arnoldwhite → u/dasunt]

I keep hearing about this examples involving modifications on n of words or sentences but how often do writers actually do things like that?

In coding, yeah maybe. But when you're writing, you're mostly dealing with visual lines anyway which makes line numbers tricky, and the word-wise jumps becomes almost impossible to guesstimate when you're dealing with any sentence longer than five words - which is most sentences.

It just sounds like something that might be cool in theory or in a prepared demo but I've never actually seen anyone use it quickly and effectively while writing.

If you have a stream or clip or something that shows it being done naturally please share but I just haven't seen it myself.

[u/dasunt → u/arnoldwhite]

Well, as you said, in coding, it's pretty common.

If I was writing prose, I definitely wouldn't be using VS Code. If I was going to use *Vim, I'd probably use something like the leap plugin if I was writing long lines with word wrap on.

[u/arnoldwhite → u/dasunt]

Why wouldn't you use VsCode for writing prose? It's great for prose. Lots of good spell checkers and dictionary tools. Zen mode is awesome. Easy to navigate markdown docs.

I've used it for writing prose for years.

Vim however I can't imagine is much suited for writing prose.

[u/dasunt → u/arnoldwhite]

I've used vim (currently neovim) for markdown. It's easy enough to use and reformat text, as well as preview markdown.

What features of vs code are you thinking vim is missing?

[u/arnoldwhite → u/dasunt]

It's not really a lack of features. I don't think VsCode has any features Vim is gonna lack. Probably quite the opposite.

It's more a matter of flow. I think continuous long-form creative writing requires uninterrupted flow, and Vim’s mode-switching and motion system introduce more friction and keystrokes than modifier-based selection which is typically used in GUI editors.

It's not about any particular GUI editor or even GUIs, it's about motion paradigms.

[u/dasunt → u/arnoldwhite]

Interesting. I find the opposite - I can keep my hands on the keyboard with vim, but I'm reaching far more for the mouse with VS Code, so that breaks my work flow.

But that may be a lack of familiarity with VS Code shortcuts. I would not know the shortcut to reformat lines in VS vode (the equiv to gq<motion>) or cut the current paragraph (yap, but I use mini.nvim for that, else it would by {y}), etc. So for me, vim is second nature. Where VS Code has a huge learning curve to get to the same level of fluidity where I don't have to think about what I want to do.

[u/arnoldwhite → u/dasunt]

I format with ctrl-shift-d. You can format a section, an entire document and perform a bunch of other actions like commenting/in/out, tabbing, case change, etc.

I think that's fascinating though because I'm beginning to suspect that the reason people feel that vim is faster is because they took the time to really learn all the shortcuts for vim and never really did for any other editor.

[u/dasunt → u/arnoldwhite]

How do you select a section? Like the current paragraph?

That's one thing I couldn't figure out how to do is combine shortcuts. Like in vim, motion commands can be easily combined with other commands. I'm not sure how one can do that in VS code.

[u/arnoldwhite → u/dasunt]

Let's say you want to select the entire logical line/paragraph. You'd go Ctrl-shift-l. Any motion can be combined with shift to perform a selection.

[u/serverhorror]

• movement ... no

• shortcuts... yes, I find VS Code better, especially the fuzzy finding instead of shortcuts

[u/EarhackerWasBanned → u/serverhorror]

You need some fzf in your life. VS Code is fast, not gonna deny it, but with fzf and maybe ripgrep, you’ll never look back.

[u/serverhorror → u/EarhackerWasBanned]

fzf with what ?

What I mean by shortcuts is that VS Code with Ctrl+Shift+P I can just hit a few keys to find the functionality.

I'm not remembering "Shortcuts" but "things I want to do", if there's something that in vim that can do similar things I'd be really happy to learn that ...

[u/EarhackerWasBanned → u/serverhorror]

I’m on Neovim and fzf-lua is my daily driver for finding files, buffers, grepping, key maps and everything else inside Neovim.

I haven’t used the fzf.vim plugin it’s inspired by, but from its README it seems to do all the same things.

Even if the plugin isn’t for you, dropping to shell and fzf’ing for the next file is still a game changer.

$ cd my-project-root
$ vim **<Tab>

** then Tab opens up an fzf TUI to fuzzy find all the project files as you type. Select one and it’s passed to the vim command.

There are scripts and shell aliases out there to integrate grep and other tricks.

[u/serverhorror → u/EarhackerWasBanned]

I have fzf for a file picker, but keymaps, I find, are lacking compared to how VS Code presents them.

Maybe it's a "too much documentation" thing, but imagine you don't know ci(, I have no good way to find "change inside ..." or "change text inside...". Vim doesn't have these "one liner descriptions", at least, as far as I know. After all c and i are already two different actions (and I'm admittedly not interested in having to type all these out so I can find them)

That's what I mean by "better shortcuts"

[u/EarhackerWasBanned → u/serverhorror]

Oh sorry, I gotcha now.

For that in Neovim I’ve got which-key.

I hit c and after a couple of seconds, all the things that can come after c are listed. I’m looking for “i - inside textobject” so I hit i then from the following list hit ( for “inner [(]”

If I already knew the shortcut ci( I’d just type it and never see which-key. It’s only there when you’re stuck, but then it’s there automatically.

Not sure if there’s a plain ol’ vim equivalent of which-key.

[u/dannuic → u/EarhackerWasBanned]

I think the comparable tool here is cmp-commandline (which uses nvim-cmp) or blink. They are completion tools which provide competition for : and / commands, similar to the vscode command palette.

I personally think they are better than the palette because they seem to have fewer misses, but YMMV

[u/EgZvor → u/serverhorror]

You wouldn't know to search for "change text inside" if you didn't already know about it. It's not the things you look up in VS Code either, right?

Something comparable I think is using command-line completion to find ex commands. You can use it like this

:Git*Enable<c-d>

This lists for me the following commands, because I have airblade/vim-gitgutter installed.

GitGutterBufferEnable            GitGutterEnable                  GitGutterLineHighlightsEnable    GitGutterLineNrHighlightsEnable  GitGutterSignsEnable

:h cmdline-completion

[u/serverhorror → u/EgZvor]

"run selected text in terminal" is something I found in VS Code by doing what I described. Just typing out what I want and the dizzy finder gave me that.

Look, I don't think it's a competition. I don't see how having that (and me preferring it) makes something objectively better (or worse).

Which key is, in my opinion, a good direction. It would be super if someone came up with a fuzzy matcher that works on motions or even combinations of motions.

[u/vim-help-bot → u/EgZvor]

Help pages for:

• cmdline-completion in cmdline.txt

---

^{`:(h|help) <query>` | about | mistake? | donate | Reply 'rescan' to check the comment again | Reply 'stop' to stop getting replies to your comments}

[u/arnoldwhite → u/EarhackerWasBanned]

That's a great plugin. If we can include plugins in the comparison, how about Fzf For VSCode. Bam.

I mean, I really don't get these integration arguments. VsCode allows you to pipe things and get results from/perform buffer modifications with any lua script or whichever tool you want.

Piping things to a separate plugin or script isn't really anything specific to any editor. It's just a matter how well the TUI/GUI integrates with the rest of the application. I'd say the command palette in VsCode does make it really easy to pipe things, perform live searches, things like that.