5 ms·

The Efficiency of Vim

55 points by bencornia 2y ago

AlienRobot 2y ago
I don't see anything here that tells me how is Vim supposed to be efficient. My experience with modality is that almost every time I want to do something I'm in the wrong mode. I thought Vim could be efficient because if you just learn all these codes you can instantly cut 5 lines of code 5dd. But in practice I can't count so I cut the wrong number of lines, then I have to look up how to undo because obviously Ctrl+Z doesn't work, and the end result pretty much every time is that I'd be more efficient with VS Code or even Notepad than with Vim. I just can't see where this "efficiency" is supposed to be at all. If you tell me I'm supposed to spend 4 weeks reading VimTutor to gain efficiency in Vim, I could probably become more efficient faster in VS Code by learning all of its keyboard shortcuts. Btw Ctrl+/ comments the current line, but I always just press home // because that feels faster. It works with multiple lines, but I just use Alt+Down key in that case to create multiple cursors.
- fstarship 2y ago
  For your specific counting problem you can use relative line numbering which shows line numbers relative to your cursor. However the larger attempt and redo problem you highlighed is mitigated in a modal editor that does selection first (not vim) instead of action so you get a preview of what you will delete before hitting it, you can also expand it. I did give up vim for the same reasons, but I am happy with Helix. I won’t deny that I still make lots of errors, I still use vscode for other features like folder search and replace, easier diff comparisons
  - cbm-vic-20 2y ago
    > a modal editor that does selection first (not vim) instead of action so you get a preview of what you will delete before hitting it, you can also expand it. This is pretty much what Visual mode does. V4jd is * V: enter visual line mode. * 4j: select the next four lines (in addition to this one) * d: delete. The selection is highlighted before the delete command, you can change the selection range, etc. I use visual mode to replace stuff all the time: V10j:s/foo/bar/g It even shows the changes interactively.
    - fstarship 2y ago
      I did actually do that when I tried Vim but it felt clunky. The find and replace is more at folder level with vscode previews only terminal equivalent I know is serpl
      - metaltyphoon 2y ago
        For that you can use a quick fix list.
  - oofabz 2y ago
    You can do selection first in Vim by using visual mode. For this particular example (5dd) you would want to use visual line mode by pressing shift-v. Then you can select the lines you wish to cut, and press d to delete them, or apply any other action to that block of text. I frequently use c (change) on my visual selections, type in new code at the point where it was removed, then use p to paste the old code somewhere else.
- atrettel 2y ago
  > My experience with modality is that almost every time I want to do something I'm in the wrong mode. The key is to almost always be in command mode. I am only in insert mode briefly to add or change text. The power of Vim comes from its terse command language, so you want to be in command mode most of the time. I find myself reflexively hitting Esc or Ctrl-[ in other programs because I have drilled this into my mind. > I just can't see where this "efficiency" is supposed to be at all. I did not see the efficiency myself until I witnessed a Vim master do some extremely complicated bit of text editing in seconds. I think that most people will not see the value of Vim until they witness something like that. > If you tell me I'm supposed to spend 4 weeks reading VimTutor to gain efficiency in Vim, I could probably become more efficient faster in VS Code by learning all of its keyboard shortcuts. Btw Ctrl+/ comments the current line. I personally found Vimtutor boring, if I recall correctly, so I did not use it to learn Vim. I just started to use Vim for all of my coding for several weeks during a slow period at work. I had a printout [1] with all of the keys next to my monitor for several weeks. That was necessary to get muscle memory for every action. I also read a lot of "Learning the vi and Vim Editors". That helps you get into the mindset about how to use the Vim command language. My point is that there are many ways to learn Vim and you can pick which way works best for yourself. [1] http://www.viemu.com/a_vi_vim_graphical_cheat_sheet_tutorial.html http://www.viemu.com/a_vi_vim_graphical_cheat_sheet_tutorial...
  - AlienRobot 2y ago
    I wish I knew what this Vim mastery looks like. I have seen people do things in VS code I don't know how to do, so I wonder if you can be really productive in Vim, or you simply never realized how productive you can be in VS code. Do people know they can use regex substitutions in VS code, for example? I'm sure Vim can do this as well, even Notepad++ has it, but it's the sort of feature most people don't know about because they just don't use regex very often.
    - atrettel 2y ago
      Vim mastery is not just regex. Regex is basically the same as using sed or grep in Vim. The key to Vim mastery is realizing that every key you press is a command in the language of Vim. Once you realize this, you can construct complicated sequences of commands that do exactly what you want without having to do it yourself manually. This is why I say that it is difficult to see how much more efficiency you can get without witnessing it yourself. It is a fundamentally different way of doing text editing. Let's just focus on navigation for a second. Yes, you can type things like "10j" to go down 10 lines. Yes, you can type "10}" to go down 10 "paragraphs" (could be functions, etc.). Or you can type "/text" to find the next instance of "text", and then type "10n" to go to the 10th instance. Once you realize all of these things, you start to think about navigating the code a lot differently, since you realize that you can make your code very structured and make it incredibly easy to navigate with just the keyboard. Let's now focus on something that would be really tedious to type but would happen instantly in Vim. Let's you you want to make an array of 100 elements for some reason. If you had to type that manually, you could have an off-by-one error or something. It's really tedious and not something you want to do yourself. Instead, you can type this in Vim: i array = [ Esc 99A 0, Esc A 0] Esc and you have an array with exactly 100 zeros. This is a simple example. You can continue this to much more complicated structures. That is the power of Vim. (Yes, if this is Python you can do the same thing with "array = [0] * 100". My point is to illustrate Vim's command language and how it changes how you approach text editing.)
- nrds 2y ago
  Counting anything in vim is an antipattern. :set rnu :set nu will change the gutter to display relative line numbers for all but the current line. FWIW I would very rarely if ever use '5dd'; to me that is spelled 'd4j'. ':set rnu' obviously influences this, since the last line to be copied is labeled '4'. Undo is 'u' and, yeah, you probably need to know that one before starting. Even after over 15 years using vim I still make tons of mistakes and change my mind, and a fairly robust undo system is crucial.
  - AlienRobot 2y ago
    I have tried setting relative numbering, but because I need to look at the gutter to read it, it would be faster to just hold shift+down in VS code if I need to do something with 5 lines of code, and if it's a lot of lines, just use the mouse, or press page down, or ctrl+shift+end if it's all the way to the end.
    - kevin_thibedeau 2y ago
      v/V mode is right there for block selection.
- dddgghhbbfblk 2y ago
  Almost any time that you might use a number to count lines or words or whatever, I just use visual mode. It's very fast and eliminates the "oops wrong number" kind of nonsense. There are other ways of navigating next besides just counting characters/words/lines as well (text objects and the like). Vim does have a big learning curve. If you don't want to invest in it, that's perfectly fine.
- koakuma-chan 2y ago
  Nobody uses 5dd, you select what you want to delete in visual mode and then delete it.
  - AlienRobot 2y ago
    So if I want to erase one word to write another, instead of ctrl+delete or ctrl+backspace, I need to switch to visual model, delete the word, switch to insert mode, and type it? Doesn't sound more efficient than VS code to me.
    - koakuma-chan 2y ago
      You need to press `ves` and type the new word. Trust me, it's really fast.
      - flykespice 2y ago
        'cw' is way faster, no need to enter visual mode (don't rely too much on it)
        koakuma-chan 2y ago
        Visual mode is way more practical because you don't always need to edit a word, you might need to edit a few words and/or things that are not words. I always use visual mode to see clearly what I'm changing.
        cbm-vic-20 2y ago
        The power of the vi-family is that this generalizes consistently. Want to replace everything from here to the next comma? 'ct,TYPE STUFF HERE' I'm not a very accurate mouser, so with a GUI editor without sufficient vi-ness, that means I need to use the mouse to drag a selection, make sure I don't also grab the tiny comma, then start typing. So annoying.
        koakuma-chan 2y ago
- nick__m 2y ago
  I agree ! For browsing/reading code, I don't see how vim can be much more efficient than a properly configure IDE that support crtl+click, the back and forward mouse buttons and a command of the keyboard shortcut.
- darkerside 2y ago
  You get used to it :) At first, err on the lower side, and 4dd. Over time, you'll start viewing things in chunks naturally, which probably only helps your code scanning ability, which is probably half the benefit of learning Vim. You get really good at looking at code like building blocks. And undo is an easy one... Just type 'u'! Like any skill or tool, it often seems not worth it before you know how to do it. But every time you learn a new skill (like you just learned undo!), it makes you more efficient for the rest of your life! How amazing is that?
- newmana 2y ago
  Smalltalk Environment - the dawn of IDEs - "Don't mode me in" "Novices are not the only victims of modes. Experts often type commands used in one mode when they are in another, leading to undesired and distressing consequences. In many systems, typing the letter "D" can have meanings as diverse as "replace the selected character by D," "insert a D before the selected character," or "delete the selected character." How many times have you heard or said, "Oops, I was in the wrong mode"?" https://archive.org/details/TheSmalltalkEnvironment https://archive.org/details/TheSmalltalkEnvironment
- 102030485868 2y ago
  > My experience with modality is that almost every time I want to do something I'm in the wrong mode. Vim tells you the mode though! Insert -> Normal/Visual: ESC, Ctrl+c, or Ctrl+[. You could also do something like, while in Insert mode press Ctrl+o to do "one movement" (e.g. "i234[Ctrl+o]^1[Ctrl+c]", or maybe, "ihelo world[Ctrl+o]2Fll[Ctrl+o]$![Ctrl+c]" -- don't type the "[" and "]"). Normal -> Insert: well... it depends on where you want to insert. > But in practice I can't count so I cut the wrong number of lines Sometimes you don't need to keep track of the number of lines. But, if you really wanted to, you could do something like: :set relativenumber If you're deleting 5 lines in, say, a CSV, this helps. If it's code or text you could also use sentence ("(" and ")") or paragraph ("{" and "}") movements like "5d)" (delete the next 5 sentences); "d{" (delete up to the previous paragraph). There's a bit of jank when it comes to code though, but there's some support for it (or maybe I'm just doing it wrong). > then I have to look up how to undo because obviously Ctrl+Z doesn't work "u" for Undo, Ctrl+r for "redo". ":help undo" goes into _way_ more detail, and it does get complicated. I don't think I've needed anything past section 2. > I just can't see where this "efficiency" is supposed to be at all. The "efficiency" comes with investment, which you can get with any editor. > If you tell me I'm supposed to spend 4 weeks reading VimTutor to gain efficiency in Vim I didn't go through vimtutor for a very long time. You can become a reasonably okay Vim user, but it does take some investment. On the order of weeks is probably correct. But honestly, VSCode is fine too. Notepad is... probably fine.
- ramses0 2y ago
  I'll share with you this video that I made ~15 years ago. https://youtu.be/PHskKxkM-nA https://youtu.be/PHskKxkM-nA ...pause it before you watch it, look at the video description, and skip to 1m23s. Grab the text from the video description in the editor of your choice, compare the before and after (heck, I'll probably go in and paste the "after/goal" so you don't even have to work at it). Time yourself in your editor of choice to match the "goal" output. Basically: `var $foo, $bar, $baz;` => `$obj = { "foo": $foo, "bar": $bar, "baz": $baz }` ...I randomly did it in about a minute, conveniently and subconsciously, and thought it was worth making a video about it (15 years ago...). Nowadays I see easy fixups (eg: `gv`, maybe a macro...) that would have made it faster, but it's not about the speed, it's about the accuracy! One of the most important "commandlets" of vim is the `.` command: "repeat last edit" In the video when I perform(!) one "change comma into an arrow", I can `n` to "next" to the next anchor point (eg: a `,`) and repeat the edit(!) Cleverly stringing together "edits" into interactive repetitions is like getting tetrises in Tetris (and about as easy, once you know to look for them). vim is not an "editor", it's an interactive programming language for editing text: `:g/def /norm 0fdf ywA #<c-r>"` ...find lines that match `def ...` (slightly sloppily), find the first 'd', find the following '<space>', yank the subsequent word (also could have yanked until a '('), and then append what was yanked as a comment. Why?! Dunno. But like 30 keystrokes and I can edit the whole file to perform that operation, or any other arbitrary operation, and I can repeat that operation on any file I'd like. It's "editing" in the sense that after a certain point you don't think about it, you just do it, and the text transformation isn't polluted by inaccuracies, as "advanced vim" encourages you to repeat, replace, define as opposed to "type". Nowadays with LLM-autocomplete, and the temptation of "whole-git-repo" refactorings like: "change all my uses of list comprehensions to for loops, and use generators, but only for api responses that come from a particular domain" ... yeah, vim feels pretty baroque. ...but when you actually need to do some editing to fix up the mess that was made by the LLM, come talk to me. ;-)
  - ahaferburg 2y ago
    It's much faster to do this with multi-cursor editing in VS code or Sublime Text. And more intuitive and way easier to learn. Select the $, Ctrl+D to select the other ones, then select and copy the identifiers. Took me 28 seconds in total.
keyle 2y ago
I'm probably going to cop a wave of negative comments, but personally I'm much faster with keyboard and mouse, traditional editor than vim. 25 years professional and going, I've given vim shortcuts a fair go. I learnt the ones I thought were making vim more efficient. But the reality is, I look first, which then I click there and I'm there. I don't have to jump between modes, the cursor is typing words. I map pageUp and pageDown to paragraphs jumping and that's about the only non traditional setup I have. I realise a lot will oppose to this reasoning, claim I don't know what I'm talking about, but maybe it's time to consider your RSI and effective speed, not perceived speed due on hammering keys, as a factor. That said, I am jealous at times, watching vim people smack some keys around, feels cool! Edit: I mostly use IntelliJ(CE) and Zed nowadays. I jump in vscode if I need to debug breakpoints on a language Intellij(CE) does not support.
- flashgordon 2y ago
  You gotta do you! I cannot survive without vim and despite having used tons of editors and ides nothing comes close to my distraction-free-ness as vim. Next best thing for me is vimbindings. Again even if you are productive in notepad nothing wrong with that! Also typing speed is not an indication of actual productivity.
- smlavine 2y ago
  I'm in university right now and am working on a semester long group project with a few other folks. It's written in C. Most (all?) of the rest of them use VS Code, I use NeoVim. I've observed that, while VS Code isn't a major limitation in writing code, Vim is a lot faster at editing code. Changing designs, data structures, similar logic across several functions, copying existing files to new locations and making minor edits. These and other tasks are so much faster with visual mode selections, Quick file-wide find and replace/ignore, freaking recording a macro and then executing it 100 times in a handful of seconds -- this is a real difference, and it scales. Maybe it's just that I'm much more familiar with the ins and outs of how to use Vim efficiently for this purpose, and maybe VS Code can be equally efficient. But when you learn Vim, these are things that you will learn -- or at least learn about -- very soon. With VS Code, you will reach a plateau you don't even know about because these are not the features that VS Code differentiates itself with -- namely, fast in-editor documentation, jump to definition, visualize file structure, etc. Useful things when writing new code fast, sure, but not necessarily editing en masse.
atrettel 2y ago
I have been telling people for years that using an editor like Vim or Emacs makes you more efficient, but I have found that most people either do not particularly care, or worse still, think that the efficiency gains are surely marginal at best. I view this as an unspoken part of Vim's learning curve. You have to realize that it is worth the time to learn. I only bothered to learn Vim after seeing somebody do some wizardry with it and wondering how they did it. But I didn't have the time to learn it then. I later had some downtime at work and was able to learn it. I imagine the learning process is similar for many people.
- mattnewton 2y ago
  I’m not convinced; I have met a lot of people who were very high on vim and spent a long time furiously typing keystrokes and planning out their changes without realizing how much time they were spending on that thinking bit. (Personally it also competes with the working memory of changes I am trying to make, but I am willing to concede that could go away with years of practice). Simpler abstractions like sublime-style multiple cursors have almost the same power without the complexity of programming your editor live. I wouldn’t recommend new people spend time on vim, unless you like, expect to find yourself in freshly initialized Linux boxes or developing on minimal hardware often.
  - lacedeconstruct 2y ago
    I thought the main idea of vim is that touch typers who are really fast can do everything without lifting their fingers from the main row, which is a really motivating reason imo, it starts to breakdown heavily when you dont already have this skill though
    - drekipus 2y ago
      This is the unspoken differentiator imo. I have seen an alarming number of programmers hunt-n-peck typing, and it's getting larger.. To them, vim is probably on-par or slower
kovrik 2y ago
I love Vim and use Vim bindings everywhere I can (Emacs, Firefox, Intellij etc.). But I don't think it is actually more efficient than traditional editing, but rather just a different way of editing which may be (or may be not) more convenient to _some_ people (myself included). Especially nowadays with modern IDEs and auto-completions and AI code helpers, it's not really about text editing anymore, it's not the bottleneck.
shmerl 2y ago
I enjoy using neovim. Though I'd argue most of the programming time is spent on thinking what to do, not on typing it. It's different when you write prose or transcribing something. Then typing speed matters way more. That said, having keyboard controls for editing actions is definitely making editing experience more convenient. Same goes for the modes switching and ability to express commands for the editor like you'd do in a shell.
theonething 2y ago
All these people claiming Vim is not efficient because they don't know how to use it well.
- koakuma-chan 2y ago
  It's more like people are simply refusing to learn it because they think VSCode is somehow good enough.
  - mustermannBB 2y ago
    To some vscode probably is good enough and that is OK. I don't see why this would be an issue.
    - koakuma-chan 2y ago
      This is an issue become the some don't know better.
      - mustermannBB 2y ago
        Or they simply think or know that vscode does what it needs to, for them to get the job done. In the end the best tool is the one you can be productive in. No need for gatekkeeping about something as trivial as ones preferred editor or IDE.
- 000ooo000 2y ago
  I usually avoid the comments on any Vim-related post because it's inevitably the same, strong opinions from people who think Vim is just the motions.
raincole 2y ago
Off topic, but it's a little weird that people now call the common editors like VSCode "traditional editors", as if Vim and Emacs were released yesterday.
jauntywundrkind 2y ago
I committed to vim sometime in the 90's, and have coded on it full-time since. But I've had very poor tooling integration, until a year or two ago. It's taken some time to grow into it, but I'm definitely enjoying having diagnostics built-in and having types helping me do autocomplete. Step-by-step debugging is fine, if not great. One of the things that I'll credit as having made a huge different is switching to AstroVim ~2 years ago. It provided a bunch of helpful, sensible leader key bindings, and a little mini dynamic TUI at the bottom of the screen to show them off. AstroVim also has an excellent community repository of ready-to-go preconfigured plugins. I'd been loath to get deep into configuring my own vim, felt overwhelmed by setting up LSP, but having these community packs ready to go has really opened up a broad interest in exploring, in seeing whats out there. Whatever language you work in, there's probably a pretty good ready-to-go setup to get good LSP support! https://github.com/AstroNvim/astrocommunity/tree/main/lua/astrocommunity/pack/typescript https://github.com/AstroNvim/astrocommunity/tree/main/lua/as... I'd done some years with Eclipse & Eclim, doing Java, long long ago. And knew there were some really important, key dev tools I was missing. Just having separate debugging programs going (or falling back to printf-style debugging), versus that being something I could do in vim was a huge sign to me that while I could edit reasonably well, I was behind the power curve of where I wanted to be in coding, in what I expect from an IDE. It's been nice to very rapidly gain ground these past couple years.

55 points by bencornia 2y ago

I don't see anything here that tells me how is Vim supposed to be efficient. My experience with modality is that almost every time I want to do something I'm in the wrong mode. I thought Vim could be efficient because if you just learn all these codes you can instantly cut 5 lines of code 5dd. But in practice I can't count so I cut the wrong number of lines, then I have to look up how to undo because obviously Ctrl+Z doesn't work, and the end result pretty much every time is that I'd be more efficient with VS Code or even Notepad than with Vim. I just can't see where this "efficiency" is supposed to be at all. If you tell me I'm supposed to spend 4 weeks reading VimTutor to gain efficiency in Vim, I could probably become more efficient faster in VS Code by learning all of its keyboard shortcuts. Btw Ctrl+/ comments the current line, but I always just press home // because that feels faster. It works with multiple lines, but I just use Alt+Down key in that case to create multiple cursors.

fstarship 2y ago
For your specific counting problem you can use relative line numbering which shows line numbers relative to your cursor. However the larger attempt and redo problem you highlighed is mitigated in a modal editor that does selection first (not vim) instead of action so you get a preview of what you will delete before hitting it, you can also expand it. I did give up vim for the same reasons, but I am happy with Helix. I won’t deny that I still make lots of errors, I still use vscode for other features like folder search and replace, easier diff comparisons
- cbm-vic-20 2y ago
  > a modal editor that does selection first (not vim) instead of action so you get a preview of what you will delete before hitting it, you can also expand it. This is pretty much what Visual mode does. V4jd is * V: enter visual line mode. * 4j: select the next four lines (in addition to this one) * d: delete. The selection is highlighted before the delete command, you can change the selection range, etc. I use visual mode to replace stuff all the time: V10j:s/foo/bar/g It even shows the changes interactively.
  - fstarship 2y ago
    I did actually do that when I tried Vim but it felt clunky. The find and replace is more at folder level with vscode previews only terminal equivalent I know is serpl
    - metaltyphoon 2y ago
      For that you can use a quick fix list.
- oofabz 2y ago
  You can do selection first in Vim by using visual mode. For this particular example (5dd) you would want to use visual line mode by pressing shift-v. Then you can select the lines you wish to cut, and press d to delete them, or apply any other action to that block of text. I frequently use c (change) on my visual selections, type in new code at the point where it was removed, then use p to paste the old code somewhere else.
atrettel 2y ago
> My experience with modality is that almost every time I want to do something I'm in the wrong mode. The key is to almost always be in command mode. I am only in insert mode briefly to add or change text. The power of Vim comes from its terse command language, so you want to be in command mode most of the time. I find myself reflexively hitting Esc or Ctrl-[ in other programs because I have drilled this into my mind. > I just can't see where this "efficiency" is supposed to be at all. I did not see the efficiency myself until I witnessed a Vim master do some extremely complicated bit of text editing in seconds. I think that most people will not see the value of Vim until they witness something like that. > If you tell me I'm supposed to spend 4 weeks reading VimTutor to gain efficiency in Vim, I could probably become more efficient faster in VS Code by learning all of its keyboard shortcuts. Btw Ctrl+/ comments the current line. I personally found Vimtutor boring, if I recall correctly, so I did not use it to learn Vim. I just started to use Vim for all of my coding for several weeks during a slow period at work. I had a printout [1] with all of the keys next to my monitor for several weeks. That was necessary to get muscle memory for every action. I also read a lot of "Learning the vi and Vim Editors". That helps you get into the mindset about how to use the Vim command language. My point is that there are many ways to learn Vim and you can pick which way works best for yourself. [1] http://www.viemu.com/a_vi_vim_graphical_cheat_sheet_tutorial.html http://www.viemu.com/a_vi_vim_graphical_cheat_sheet_tutorial...
- AlienRobot 2y ago
  I wish I knew what this Vim mastery looks like. I have seen people do things in VS code I don't know how to do, so I wonder if you can be really productive in Vim, or you simply never realized how productive you can be in VS code. Do people know they can use regex substitutions in VS code, for example? I'm sure Vim can do this as well, even Notepad++ has it, but it's the sort of feature most people don't know about because they just don't use regex very often.
  - atrettel 2y ago
    Vim mastery is not just regex. Regex is basically the same as using sed or grep in Vim. The key to Vim mastery is realizing that every key you press is a command in the language of Vim. Once you realize this, you can construct complicated sequences of commands that do exactly what you want without having to do it yourself manually. This is why I say that it is difficult to see how much more efficiency you can get without witnessing it yourself. It is a fundamentally different way of doing text editing. Let's just focus on navigation for a second. Yes, you can type things like "10j" to go down 10 lines. Yes, you can type "10}" to go down 10 "paragraphs" (could be functions, etc.). Or you can type "/text" to find the next instance of "text", and then type "10n" to go to the 10th instance. Once you realize all of these things, you start to think about navigating the code a lot differently, since you realize that you can make your code very structured and make it incredibly easy to navigate with just the keyboard. Let's now focus on something that would be really tedious to type but would happen instantly in Vim. Let's you you want to make an array of 100 elements for some reason. If you had to type that manually, you could have an off-by-one error or something. It's really tedious and not something you want to do yourself. Instead, you can type this in Vim: i array = [ Esc 99A 0, Esc A 0] Esc and you have an array with exactly 100 zeros. This is a simple example. You can continue this to much more complicated structures. That is the power of Vim. (Yes, if this is Python you can do the same thing with "array = [0] * 100". My point is to illustrate Vim's command language and how it changes how you approach text editing.)
nrds 2y ago
Counting anything in vim is an antipattern. :set rnu :set nu will change the gutter to display relative line numbers for all but the current line. FWIW I would very rarely if ever use '5dd'; to me that is spelled 'd4j'. ':set rnu' obviously influences this, since the last line to be copied is labeled '4'. Undo is 'u' and, yeah, you probably need to know that one before starting. Even after over 15 years using vim I still make tons of mistakes and change my mind, and a fairly robust undo system is crucial.
- AlienRobot 2y ago
  I have tried setting relative numbering, but because I need to look at the gutter to read it, it would be faster to just hold shift+down in VS code if I need to do something with 5 lines of code, and if it's a lot of lines, just use the mouse, or press page down, or ctrl+shift+end if it's all the way to the end.
  - kevin_thibedeau 2y ago
    v/V mode is right there for block selection.
dddgghhbbfblk 2y ago
Almost any time that you might use a number to count lines or words or whatever, I just use visual mode. It's very fast and eliminates the "oops wrong number" kind of nonsense. There are other ways of navigating next besides just counting characters/words/lines as well (text objects and the like). Vim does have a big learning curve. If you don't want to invest in it, that's perfectly fine.
koakuma-chan 2y ago
Nobody uses 5dd, you select what you want to delete in visual mode and then delete it.
- AlienRobot 2y ago
  So if I want to erase one word to write another, instead of ctrl+delete or ctrl+backspace, I need to switch to visual model, delete the word, switch to insert mode, and type it? Doesn't sound more efficient than VS code to me.
  - koakuma-chan 2y ago
    You need to press `ves` and type the new word. Trust me, it's really fast.
    - flykespice 2y ago
      'cw' is way faster, no need to enter visual mode (don't rely too much on it)
      - koakuma-chan 2y ago
        Visual mode is way more practical because you don't always need to edit a word, you might need to edit a few words and/or things that are not words. I always use visual mode to see clearly what I'm changing.
      - cbm-vic-20 2y ago
        The power of the vi-family is that this generalizes consistently. Want to replace everything from here to the next comma? 'ct,TYPE STUFF HERE' I'm not a very accurate mouser, so with a GUI editor without sufficient vi-ness, that means I need to use the mouse to drag a selection, make sure I don't also grab the tiny comma, then start typing. So annoying.
        koakuma-chan 2y ago
nick__m 2y ago
I agree ! For browsing/reading code, I don't see how vim can be much more efficient than a properly configure IDE that support crtl+click, the back and forward mouse buttons and a command of the keyboard shortcut.
darkerside 2y ago
You get used to it :) At first, err on the lower side, and 4dd. Over time, you'll start viewing things in chunks naturally, which probably only helps your code scanning ability, which is probably half the benefit of learning Vim. You get really good at looking at code like building blocks. And undo is an easy one... Just type 'u'! Like any skill or tool, it often seems not worth it before you know how to do it. But every time you learn a new skill (like you just learned undo!), it makes you more efficient for the rest of your life! How amazing is that?
newmana 2y ago
Smalltalk Environment - the dawn of IDEs - "Don't mode me in" "Novices are not the only victims of modes. Experts often type commands used in one mode when they are in another, leading to undesired and distressing consequences. In many systems, typing the letter "D" can have meanings as diverse as "replace the selected character by D," "insert a D before the selected character," or "delete the selected character." How many times have you heard or said, "Oops, I was in the wrong mode"?" https://archive.org/details/TheSmalltalkEnvironment https://archive.org/details/TheSmalltalkEnvironment
102030485868 2y ago
> My experience with modality is that almost every time I want to do something I'm in the wrong mode. Vim tells you the mode though! Insert -> Normal/Visual: ESC, Ctrl+c, or Ctrl+[. You could also do something like, while in Insert mode press Ctrl+o to do "one movement" (e.g. "i234[Ctrl+o]^1[Ctrl+c]", or maybe, "ihelo world[Ctrl+o]2Fll[Ctrl+o]$![Ctrl+c]" -- don't type the "[" and "]"). Normal -> Insert: well... it depends on where you want to insert. > But in practice I can't count so I cut the wrong number of lines Sometimes you don't need to keep track of the number of lines. But, if you really wanted to, you could do something like: :set relativenumber If you're deleting 5 lines in, say, a CSV, this helps. If it's code or text you could also use sentence ("(" and ")") or paragraph ("{" and "}") movements like "5d)" (delete the next 5 sentences); "d{" (delete up to the previous paragraph). There's a bit of jank when it comes to code though, but there's some support for it (or maybe I'm just doing it wrong). > then I have to look up how to undo because obviously Ctrl+Z doesn't work "u" for Undo, Ctrl+r for "redo". ":help undo" goes into _way_ more detail, and it does get complicated. I don't think I've needed anything past section 2. > I just can't see where this "efficiency" is supposed to be at all. The "efficiency" comes with investment, which you can get with any editor. > If you tell me I'm supposed to spend 4 weeks reading VimTutor to gain efficiency in Vim I didn't go through vimtutor for a very long time. You can become a reasonably okay Vim user, but it does take some investment. On the order of weeks is probably correct. But honestly, VSCode is fine too. Notepad is... probably fine.
ramses0 2y ago
I'll share with you this video that I made ~15 years ago. https://youtu.be/PHskKxkM-nA https://youtu.be/PHskKxkM-nA ...pause it before you watch it, look at the video description, and skip to 1m23s. Grab the text from the video description in the editor of your choice, compare the before and after (heck, I'll probably go in and paste the "after/goal" so you don't even have to work at it). Time yourself in your editor of choice to match the "goal" output. Basically: `var $foo, $bar, $baz;` => `$obj = { "foo": $foo, "bar": $bar, "baz": $baz }` ...I randomly did it in about a minute, conveniently and subconsciously, and thought it was worth making a video about it (15 years ago...). Nowadays I see easy fixups (eg: `gv`, maybe a macro...) that would have made it faster, but it's not about the speed, it's about the accuracy! One of the most important "commandlets" of vim is the `.` command: "repeat last edit" In the video when I perform(!) one "change comma into an arrow", I can `n` to "next" to the next anchor point (eg: a `,`) and repeat the edit(!) Cleverly stringing together "edits" into interactive repetitions is like getting tetrises in Tetris (and about as easy, once you know to look for them). vim is not an "editor", it's an interactive programming language for editing text: `:g/def /norm 0fdf ywA #<c-r>"` ...find lines that match `def ...` (slightly sloppily), find the first 'd', find the following '<space>', yank the subsequent word (also could have yanked until a '('), and then append what was yanked as a comment. Why?! Dunno. But like 30 keystrokes and I can edit the whole file to perform that operation, or any other arbitrary operation, and I can repeat that operation on any file I'd like. It's "editing" in the sense that after a certain point you don't think about it, you just do it, and the text transformation isn't polluted by inaccuracies, as "advanced vim" encourages you to repeat, replace, define as opposed to "type". Nowadays with LLM-autocomplete, and the temptation of "whole-git-repo" refactorings like: "change all my uses of list comprehensions to for loops, and use generators, but only for api responses that come from a particular domain" ... yeah, vim feels pretty baroque. ...but when you actually need to do some editing to fix up the mess that was made by the LLM, come talk to me. ;-)
- ahaferburg 2y ago
  It's much faster to do this with multi-cursor editing in VS code or Sublime Text. And more intuitive and way easier to learn. Select the $, Ctrl+D to select the other ones, then select and copy the identifiers. Took me 28 seconds in total.

keyle 2y ago

I'm probably going to cop a wave of negative comments, but personally I'm much faster with keyboard and mouse, traditional editor than vim. 25 years professional and going, I've given vim shortcuts a fair go. I learnt the ones I thought were making vim more efficient. But the reality is, I look first, which then I click there and I'm there. I don't have to jump between modes, the cursor is typing words. I map pageUp and pageDown to paragraphs jumping and that's about the only non traditional setup I have. I realise a lot will oppose to this reasoning, claim I don't know what I'm talking about, but maybe it's time to consider your RSI and effective speed, not perceived speed due on hammering keys, as a factor. That said, I am jealous at times, watching vim people smack some keys around, feels cool! Edit: I mostly use IntelliJ(CE) and Zed nowadays. I jump in vscode if I need to debug breakpoints on a language Intellij(CE) does not support.

flashgordon 2y ago
You gotta do you! I cannot survive without vim and despite having used tons of editors and ides nothing comes close to my distraction-free-ness as vim. Next best thing for me is vimbindings. Again even if you are productive in notepad nothing wrong with that! Also typing speed is not an indication of actual productivity.
smlavine 2y ago
I'm in university right now and am working on a semester long group project with a few other folks. It's written in C. Most (all?) of the rest of them use VS Code, I use NeoVim. I've observed that, while VS Code isn't a major limitation in writing code, Vim is a lot faster at editing code. Changing designs, data structures, similar logic across several functions, copying existing files to new locations and making minor edits. These and other tasks are so much faster with visual mode selections, Quick file-wide find and replace/ignore, freaking recording a macro and then executing it 100 times in a handful of seconds -- this is a real difference, and it scales. Maybe it's just that I'm much more familiar with the ins and outs of how to use Vim efficiently for this purpose, and maybe VS Code can be equally efficient. But when you learn Vim, these are things that you will learn -- or at least learn about -- very soon. With VS Code, you will reach a plateau you don't even know about because these are not the features that VS Code differentiates itself with -- namely, fast in-editor documentation, jump to definition, visualize file structure, etc. Useful things when writing new code fast, sure, but not necessarily editing en masse.

atrettel 2y ago

I have been telling people for years that using an editor like Vim or Emacs makes you more efficient, but I have found that most people either do not particularly care, or worse still, think that the efficiency gains are surely marginal at best. I view this as an unspoken part of Vim's learning curve. You have to realize that it is worth the time to learn. I only bothered to learn Vim after seeing somebody do some wizardry with it and wondering how they did it. But I didn't have the time to learn it then. I later had some downtime at work and was able to learn it. I imagine the learning process is similar for many people.

mattnewton 2y ago
I’m not convinced; I have met a lot of people who were very high on vim and spent a long time furiously typing keystrokes and planning out their changes without realizing how much time they were spending on that thinking bit. (Personally it also competes with the working memory of changes I am trying to make, but I am willing to concede that could go away with years of practice). Simpler abstractions like sublime-style multiple cursors have almost the same power without the complexity of programming your editor live. I wouldn’t recommend new people spend time on vim, unless you like, expect to find yourself in freshly initialized Linux boxes or developing on minimal hardware often.
- lacedeconstruct 2y ago
  I thought the main idea of vim is that touch typers who are really fast can do everything without lifting their fingers from the main row, which is a really motivating reason imo, it starts to breakdown heavily when you dont already have this skill though
  - drekipus 2y ago
    This is the unspoken differentiator imo. I have seen an alarming number of programmers hunt-n-peck typing, and it's getting larger.. To them, vim is probably on-par or slower

kovrik 2y ago

I love Vim and use Vim bindings everywhere I can (Emacs, Firefox, Intellij etc.). But I don't think it is actually more efficient than traditional editing, but rather just a different way of editing which may be (or may be not) more convenient to _some_ people (myself included). Especially nowadays with modern IDEs and auto-completions and AI code helpers, it's not really about text editing anymore, it's not the bottleneck.

shmerl 2y ago

I enjoy using neovim. Though I'd argue most of the programming time is spent on thinking what to do, not on typing it. It's different when you write prose or transcribing something. Then typing speed matters way more. That said, having keyboard controls for editing actions is definitely making editing experience more convenient. Same goes for the modes switching and ability to express commands for the editor like you'd do in a shell.

theonething 2y ago

All these people claiming Vim is not efficient because they don't know how to use it well.

koakuma-chan 2y ago
It's more like people are simply refusing to learn it because they think VSCode is somehow good enough.
- mustermannBB 2y ago
  To some vscode probably is good enough and that is OK. I don't see why this would be an issue.
  - koakuma-chan 2y ago
    This is an issue become the some don't know better.
    - mustermannBB 2y ago
      Or they simply think or know that vscode does what it needs to, for them to get the job done. In the end the best tool is the one you can be productive in. No need for gatekkeeping about something as trivial as ones preferred editor or IDE.
000ooo000 2y ago
I usually avoid the comments on any Vim-related post because it's inevitably the same, strong opinions from people who think Vim is just the motions.

raincole 2y ago

Off topic, but it's a little weird that people now call the common editors like VSCode "traditional editors", as if Vim and Emacs were released yesterday.

jauntywundrkind 2y ago

I committed to vim sometime in the 90's, and have coded on it full-time since. But I've had very poor tooling integration, until a year or two ago. It's taken some time to grow into it, but I'm definitely enjoying having diagnostics built-in and having types helping me do autocomplete. Step-by-step debugging is fine, if not great. One of the things that I'll credit as having made a huge different is switching to AstroVim ~2 years ago. It provided a bunch of helpful, sensible leader key bindings, and a little mini dynamic TUI at the bottom of the screen to show them off. AstroVim also has an excellent community repository of ready-to-go preconfigured plugins. I'd been loath to get deep into configuring my own vim, felt overwhelmed by setting up LSP, but having these community packs ready to go has really opened up a broad interest in exploring, in seeing whats out there. Whatever language you work in, there's probably a pretty good ready-to-go setup to get good LSP support! https://github.com/AstroNvim/astrocommunity/tree/main/lua/astrocommunity/pack/typescript https://github.com/AstroNvim/astrocommunity/tree/main/lua/as... I'd done some years with Eclipse & Eclim, doing Java, long long ago. And knew there were some really important, key dev tools I was missing. Just having separate debugging programs going (or falling back to printf-style debugging), versus that being something I could do in vim was a huge sign to me that while I could edit reasonably well, I was behind the power curve of where I wanted to be in coding, in what I expect from an IDE. It's been nice to very rapidly gain ground these past couple years.