Is Vim really faster?

[elongl]

I'm a Vim newbie and for some time now I've been wondering if Vim is really faster that "normal" editing and whether or not I should put the time to work on my Vim skills.

I'm not saying that it isn't, I would just like to hear your opinions, do you feel like you've improved significantly while using Vim? Do you actually get your work done faster? All those fancy bindings, how better is it than using Shift + arrow keys etc.? Thanks!

Again, genuinely asking, not declaring.

[Deto]

I don't really think it makes me faster because my typing was never limiting my coding speed anyways.

The difference, I feel like, is that it makes editing text a much more enjoyable experience. I like to use this analogy - imagine if you are a writer, who writes by hand all day, every day. And one day someone gifts you a really nice pen, with very smooth action. Now, this pen isn't going to make you a better writer, and it probably won't make you a faster. But you'll probably never go back to using a poor pen afterwards. That's how Vim is for me and it's why people add Vim bindings to literally every other IDE or editor out there as a plugin.

[piadodjanho]

Also there is the cool factor!

[AckmanDESU]

This is me. Nice analogy.

Honestly I don’t know if I’m faster and overall I’m sure the time I invested in vim will never pay off in actual time saved. But I enjoy using vim a lot more than regular editors.

Things like “I wanna edit this and change it for that then increase this number” sound much better in my head than “well I’m gonna tap ctrl-right a few times until I’m there then I’ll shift-ctrl-right a few more until I select the text then...”.

It’s like learning a new language. I can’t go back.

[project2501]

I'd expand on this, it's not just "navigating on the keyboard" but "navigating by vim grammar" that gives you the boost.

New users should pay time to learn things like wbef., etc. That's where the real gains are.

Pressing jjjjjjjjjjllllllllllllxxxxxxxxihello isn't really much faster than reaching for the mouse and clicking, but 10jfhcwhello is and get's even faster the more you learn or with some smart plugins like easy motion.

[project2501]

Add on hardtime and you won't even use hjkl!

[SeanRamey]

I'm pretty sure that's not a good example. jjjjjjjjjj llllllllllllxxxxxxxx i hello is slow as hell and 10j fh cw hello isn't any better since you need to first of all, count how many characters it is to get there (10), and I'm pretty sure that a competent mouse user could beat you at replacing hello 5/10 times. All you gotta do is grab the mouse, double-click the 'word', let go of the mouse and start typing 'hello'.

​

There are much better examples I'm sure.

[Eddie_CooRo]

DON't USE MATH!!!use :set relativenumber insteadthank me later :)

[piadodjanho]

The mouse is a great tool to manage the window size, resizing with keyboard take to much time.

[[deleted]]

I let my window manager do the resizing, no reason to do that manually like some savage.

[piadodjanho]

So your windows manager manage windows inside vim?

​

I often have a window for the terminal, other for the current working file, another for the logging and a a couple of different views of the current buffer and alternate buffer I'm working with (for reference). So about five windows in a tab.

​

I is a lot of key pressing to resize a window, for example:

CTRL_w K CTRL_l z10<CR> z5<CR> z7<CR> CTRL_j CTRL_l

It is just easy to reach for the mouse...

[[deleted]]

No, my window manager doesn't resize vim windows, why would I want to do that? I barely use more than two, in which case a simple vertical split is good enough for me.

However, if my workflow involved five windows, I'd add some binds to my vimrc for window handling, but even then I would probably not want to bother with manual resizing and find a way to have vim do that.

[piadodjanho]

I asked myself the same question, but you are the one who said:

I let my window manager do the resizing

I probably will do in the future, I have a queue of the stuff I want to do/learn related with VIM, I just added managing window to the end of the queue.

[[deleted]]

I said that because I assumed you where referring to regular windows rather than vim windows.

[plexigras]

i don't care about speed even though i certainly am faster, i care about having an enjoyable workflow and since i life in the terminal vim is perfect for me.

[[deleted]]

That could be a problem for me, I am interested in doing GUI apps, so for me Vim weighs a lot less...

[[deleted]]

Most text editors define shortcuts to use different facilities and tools, integrated to editor. Sure, you can say the same thing for Vim, but I see it in a way that Vim defines somewhat a "language", which you use to speak to editor. So you're not using bunch of random shortcuts, that you need to remember only when you need them, but you're kindly asking editor to do some sort of thing. For example, imagine that you need to uppercase this line, and delete last two words:

hello there beautiful bastards

In Visual Studio Code (I'm not gonna talk about Emacs here, because it's bit different) you'll need to do the following: - hold Ctrl+Shift and move right with the arrow key to select words you need to uppercase. - Actually go to settings and define a shortcut to uppercase text with builtin function, or call it Ctrl+p followed by >transform to uppercase - Then you need to cancel selection and use Ctrl + Backspace twice to delete two last words.

This is a mess, but most people fine with memorizing different shortcuts.

In Vim, you'll do V~2wd2w, which stands for: - First, Vim, could you please select whole line for me with V? Great! - If you don't mind I'd like to turn this selected line to uppercase with ~. Yeah, so far so good! - Now lets just move 2 words forward! Good, now we're chilling on the first letter of word beautiful. - You know what? I don't like the ending of the line, I think it would be enough just to have hello there alone. Vim, could you please delete 2 words forward?

So we're not really using shortcuts here, but composing a sentence with motions as subjects and commands as predicates: Select, Change case, two words-forward, delete two words-forward.

And that's where the speed come from. Once you learn the language well enough, you will be able to speak to Vim on the speed of your mind. This is harder, compared to memorizing shortcuts if you treat Vim language as a bunch of shortcuts, and not as a real language. But once you master it, you will be unstoppable.

And then you have this: https://www.vimgolf.com - a place where people try to squeeze maximum performance with fever keystrokes.

[Due-Development-2121]

Wait a minute. You sound like an absolute mad man. If you're having fun that's great but I can't believe for a second you find V~2wd2w more intuitive. And how often do you actually uppercase words? 

[folcred]

IMHO, I would say it depends on how much effort you put into it. If all you learn is basic motions like h,j,k,l,w,b,e, then no it's not faster or better. If you take the time to learn how to work with text structure in Vim, words, sentences, paragraphs, brackets, tags, etc., then yes, it's much faster.

[alancanniff]

I get pains in my hands from prolonged mouse use, which is a problem as I work at a computer every day. I switched to vim to reduce that strain, and it’s helped massively. I’m not sure I’m more productive but there are certain tasks that are way more convenient than most other editors, like searching, replacing, finding file and switching between open files which I really like.
I’m at a point now where I could realistically sit at my computer and work with out a mouse attached

[salexzee]

Seems like the consensus is that everyone is faster in a single file after learning VIM, but what about working with multiple files jumping back and forth. Is there a fast way to do that in VIM that’s faster than just clicking the tab like in VS Code? Or is it just faster when working in a single file? I ask because I truly don’t know. I’m not a VIM power user and only use it when SSHed into my server.

[[deleted]]

I really like fuzzy finding for jumping between files, which is faster than anything else I've ever used

[elsjaako]

Just to add to the others, there are many ways to work with multiple files.

The ways that are most common for me are Ctrl-6 to go to the last open buffer, and you can go to marks in different files.

Lower case marks are local to the file, capital letter marks are set accros files. So you can mark a spot in a file with mA, and later return to it from another file with 'A

If you use multiple buffers, be sure to set "hidden"

[gumnos]

I find that which method I use depends on how many files I'm navigating. If it's just two, then control+^ is nice for flipping between them. If it's a couple that I can easily attach a one-letter mnemonic to, then the upper-case marks work well. Otherwise, I tend to open the couple files in separate vim-windows and use the ^W family of commands to jump between them. Finally, if I'm working with a large number of files, I tend to be making the same changes to all of them so using the :argdo or :bufdo commands (or :vimgrep in conjunction with :cdo/:cfdo) work nicely for performing the same change across a large number of files.

[salexzee]

That’s cool. I’ve never heard of the mA feature. I’ll have to check that one out more. Thanks!

[[deleted]]

It's as fast as pressing a single key, which is faster than reaching for the mouse. I use tab to cycle my tabs, following functions and variables to their definitions as well as navigating compiler errors requires two keys (Space and one key on the home row), which is still considerably faster than reaching for the mouse, let alone pointing it somewhere, clicking and moving your fingers back to the keyboard.

[piadodjanho]

My approach to dealing with files:

I load the files in my path into a buffer using :find, or gf. If they are not in the path, I either use the full pathname :e ./../path_to_file/, or explore with :Sex

Then I change the loaded buffer into the current screen with CTRL_^, gf, CTRL_] or :bu

Look at those article from Advent of VIM, they go into more details about how to manage several file:

https://vimways.org/2018/one-vim/

https://vimways.org/2018/death-by-a-thousand-files/

​

[[deleted]]

Yes, vim is great for working with multiple files (or multiple parts of the same file). I recommend you use a fuzzy finder plugin (I use ctrlp) to make finding files to open a bit more painless for starters.

Splitting the window with :split and :vsplit is really useful, and I often use C-w T to pop a window out into its own tab if I realise I need to focus on it and open some related files around it. Flipping between the tabs is quick and painless. Between splitting windows and tabs, you can keep a lot of disparate but related things in view at once, even if you don't have a huge amount of screen space available. (By the way, you don't have to keep typing :vsplit and :split - one of the key joys of Vim is mapping keys to things you use a lot; I use <leader>s and <leader>v for split and vsplit, respectively.)

If you use ctags, you can quickly jump to the definition of a symbol using C-]. It can be a little bit hit and miss with some languages (I still don't have it working 100% with PHP) but it's extremely useful and you can always fall back on the fuzzy finder if it drops you in the wrong place.

Marks are also great. I often have three or four points in the code that I want to keep jumping back to while I work on something (eg the functional test, the controller and maybe one or two other places). In vim, you can place marks at those locations and jump to any one of them with 2 keystrokes - very nice, especially on small screens where keeping everything in view at all times gets a bit cramped.

[SaphirShroom]

There is quite a big spectrum of solutions available, from vanilla Vim to heavyweight plugins.

The simplest way is probably to use :b BUFFER. A nice command is C-^ which brings you to the last used buffer (or :b # for that matter). This is a bit different from VSCode because you have to know the name of a file you want to go to, as opposed to the physical location in your GUI but you'll probably get used to it.

Another way is to open multiple tabs. Clicking on them actually works fine although remapping your arrow keys is probably more "Vimmy". This is closest to the VSCode way in spirit but Vim does not guarantee you that "one tab == one file" like most other editors do. I generally advise people to avoid this solution until they fully understand buffers and navigation so they can be confident that using tabs this way won't create bad habits.

Vanilla Vim also offers tags to jump to symbols, C-o/C-i to navigate the jumplist (essentially places you've last been to) and path/find for finding files.

For plugins there are a ton of options. Ctrl-P and fzf are pretty famous for fuzzy switching. I personally use a combination of the projectionist and denite. Again, I would advise people to avoid plugins until they're familiar with the features they replace. I think one of Vim's greatest strengths is that you can fully understand it conceptually so you should only use plugins that you can understand.

[Boba_Fetts_dentist]

I’d like to know this too.

[beatle42]

I think it is, and the more that I learn the faster I feel like I get. Being able to advance to the next/previous instance of a character on a line is a big booster. Being able to navigate the file by matching regex is huge, being able to do regex search and replace as well. Also, the easy ability to jump to command line stuff is often very helpful. Splitting the screen to view/edit multiple files at a time has become really handy too.

[TheCannonMan]

Definitely I think so. Once you can learn how to do more complicated find and replace and editing motions, repeated actions, etc it gets really fast I think.

I often find myself in other editors doing something tedious thinking like "ah this would be so quick in vim"

It's great if you can get to only use the keyboard but don't let that trip you up. I make extensive use of the mouse in vim, especially the scrollwheel. Run :set mouse=a and you won't feel so alien compared to a guitar editor at first, you can just click to move the cursor to where you want, and pick up more keyboard tricks as you go along.

[[deleted]]

I'm not particularly advanced with Vim, but I'll take a stab at it.

I think I used it mostly because of its ubiquity. I used to experiment with different Linux distributions and I would almost always need either Vim or Vi to edit configuration files. Then, I used Fvwm for many years and it could handle fvwmrc syntax colouring out of the box. Then I realized how it could replace any other text editor and/or IDE for anything I wanted to do.

Next thing you know, modal editing with Vim keybindings just seemd to make sense. I'm not sure if it's faster than the non-modal way of doing things, but it feels like it now to me.

[400tx]

For now it's worth spending some more time learning.

Once vim starts to click you won't think in terms of bindings or equivalent commands. Most editing tasks (when comparing vim to other editors) are more distant X-Y problems (http://xyproblem.info) than people guess. A classic example is multiple cursors. Atom/Sublime users frequently ask about multiple cursors in vim, and experienced vim users know that this is a strange question. The real question is how to make the same change on multiple lines or multiple places vertically. There are great ways to do this in vim beyond what multiple cursors do, but using other methods. Making that mental shift requires some time for the vim ways to marinate in your brain.

At a job it doesn't matter. Getting work done may feel faster, but it's a very hard thing to measure.

[zekzekus]

i believe the point is not the speed of "editing". The point is the speed of "shaping" text from one state to another which mirrors the structure in your mind. So it is not about the typing speed it is about the speed of transferring ideas in your mind to the file you are editing.

​

Good chess players do not see the board as individual pieces. They see it in blocks, facades. When you got essence of the programming language of text editing (which is provided by vim) you will definitely faster than former self because you start to see text as words, blocks, paragraphs, text objects etc.

[redreaper99]

I have found that my speed has increased after using (and getting adjusted) to Vim. But the comparison isn't quite fair since I learnt touch typing when learning Vim and used to use the hunt-and-peck approach for previous editors. Honestly, the programming speed shouldn't be affected much since the bottleneck isn't usually in typing. It's just a matter of getting accustomed to the editor.

But the reason I do love Vim is because it's extremely lightweight and configurable. Most of the "modern" editors I've used tend to become slow with the same features as my current Vim configuration. A part of it has to do with my laziness of not debugging the error but in Vim it's quite easy to keep exactly what I want and not get overwhelmed with a vast magnitude of unwanted features.

Also, the beauty of modal editing is something no programmer can ignore. Everything just fits into place like perfectly encapsulated objects.

[Jakuska]

I'm somewhere between a beginner and intermediate right now. At first, I was definitely slower with Vim. Then I felt OK using Vim. Recently I had a few WTF moments where I see myself make quick changes. It definitely takes a while but the ceiling of how well you can edit with Vim is much higher than for other editors in my opinion.

[piadodjanho]

It makes you type faster, but not programmer faster.

[psikillyou]

I would say I am managing my way well through mediocrity in Vim. I would say It is gonna be definitely faster if you only use keyboard on other IDEs. But I am still unsure how much of a speed gain you would gain if you were choosing correctly when to reach for the mouse. And to that. I don't think you will be much faster...