Skip Navigation
Ask Experienced Devs @programming.dev
I Cast Fist @programming.dev

Users of Vim and similars, what exactly makes it useful compared to other text editors? How much time do you suppose you save when working with it?

I'd like actual examples instead of "I work faster", something like "I can move straight to the middle of the file with 7mv" or "I can keep 4 different text snippets in memory and paste each with a number+pt, like 2pt", things that you actually use somewhat frequently instead of what you can do, but probably only did once.

71 comments

  • Its not so much about the time saved its about being allowed to stay in a mental state of flow since all actions in Vim and similars are built from foundational navigation language chunks. It feels less like editing and more like communicating. All these random little "I can do this command" is just people trying to show examples of how the language of editing to do weird and interesting things. So the answer isn't so much "I work faster" in Vim as it is "I work with less mental overhead in Vim"

  • I've been using vim as my daily driver for development for the last 8 years.

    There are a million things I could talk about regarding vim's editing language, consistent interface, scriptability, performance (seriously, I've opened 1GB+ files and vim barely breaks a sweat), etc., but one thing I'll highlight that most people don't talk about is vim's ability to interface with other tools. It's what takes vim from a great editor into a full-fledged development environment. You can:

    • Read the stdout of any shell program into a vim buffer (:help read !)
    • Use the contents of a buffer as stdin to any shell program (:help write !)
    • Filter a portion of the buffer through any shell program, replacing the contents with that program's stdout (:help !)
    • Parse the output of a program or the contents of a file into a set of entries for quick navigation (:help quickfix, :help make)
    • Insert the output of a shell program into the current buffer (:help <C-R>=, specifically when used with the :help system() function)
    • Control arbitrary jobs with vimscript and communicate back and forth with code

    And much more. I use all of these every day: the output of git commands give me filepaths I can jump to with gf; a range in vim selected with the v command gives me line numbers to pass to git log -L to see the history of a section of code; the current filepath of the vim buffer is pass to many different shell commands to do processing with that file; the symbol under the cursor is passed as an argument to the open command on macos to lookup external (company-specific) documentation in a Web browser. And many, many other things. Unix is my IDE, and vim is at the heart of it.

    • And here I am proud that I can open a file, save it, make edits, jump to the beginning/end, and quit it. 😅

  • I've been using vi since my mentor at an internship sat me down with a copy of "Unix in a Nutshell" and told me to learn it. This was before I discovered Vim, so I think I was using nvi which had very limited in-editor help. It was a struggle, especially compared to the resources available today.

    Around the same time, circa 1999, Tom Christiansen (of Perl fame) wrote an essay called "Zenclavier: Extreme Keyboarding" which still speaks to me, and is worth the read.

    In brief, I've never been able to "zen out" in a typical non-model text editor, at least not the way I can with neovim. It's hard for me to overstate how great it is to not have to reach for the mouse - or even outside the home row of the keyboard. Christiansen calls this the "penalty zone" - any time you need to move your fingers away from home row, you're breaking flow. And when programming, it's something we have to do all the time!

    There are other editors that support this kind of thing, like Emacs. Even VS Code and Visual Studio can be navigated entirely with the keyboard if you're willing to memorize their keybindings. But they generally rely on "chorded" keystrokes, which put your fingers into sometimes tortured positions (the old unix editor holy war joke is that Emacs stands for "Escape Meta Alt Ctrl Shift"). And often you still have to reach for keys in the "penalty zone", like PgUp/PgDn/Home/End.

    I'm biased, having used vim keybindings in basically every editor I've programmed in for the last 25 years. It would be impossible for me to go back now. There are other modal editors, like Helix and Kakoune. They're basically like vi, but they reverse the order of the keybinds - which has some really nice features, and I might even suggest you try those before getting sucked into vim-land like me. But I do think modal editing, in general, is where it's at for pure text. Especially programming, but I use it all the time for other tasks like formatting textual data files interactively.

    Anyway. Maybe it's a cop-out, but I think it's something you have to experience to really appreciate.

  • One of my favorite emacs features is the VHDL stutter mode (which replaces certain repeatedly-typed characters with operators), as well as an easy to get to rectangle select, and it just being decently fast compared to something like VSCode. I also never have to take my hands off of the keyboard, because it's all right there. It just feels better to me.

  • One thing I haven't seen mentioned is that not moving between mouse and keyboard so much reduces the risk of getting an RSI. So even if it didn't make you faster it would still probably be worth it to find a keyboard based workflow.

    I use Helix and would suggest you try it (at least to start off with) as it is easier to learn than vim and does not require plugins or a complex config. To answer your question I will go from the less to more advanced/complex:

    1. Move a line to a new position in the file/another file (takes a couple of seconds)
      1. x then d to select a line (pressing N times will select N lines) and delete it (delete will also copy to the clipboard)
      2. navigate the cursor to the new location
      3. p to paste in a new
    2. Navigating around a file:
      1. jumping to a function/class definition by pressing g then d when on a function/class usage.
      2. getting a list and navigating to class/function calls when the cursor is on a class/function definition by pressing g then r.
    3. Multi cursor editing - I use this to make edits to multiple places at once. I most recently used this to extract the names of 30 tables that are used in a SQL file. This probably took ~5 seconds and I barely thought about it. To do this I used:
      1. % to select the entire files contents
      2. s to search
      3. typed "FROM "
      4. pressed enter to create cursor at all locations matching the search
      5. v then g then l to select the rest of the line
      6. space+y to copy to the system clipboard.
      7. paste into a document where I needed to list the tables
    4. Using a terminal workspace manager (zellij) with helix and a git tui app (gitui) so that I can easily make code changes, commit, push, ,run tests, move to a new repo and more without leaving the keyboard.

    There is actually a helix community on programming.dev: helix@programming.dev

  • Sysadmin rather than dev here, but magit was what converted me to emacs. And then, at some point, it clicked that the whole shell uses the same (where applicable) shortcuts as emacs. Or, more likely, the other way around. Anyway, point being - what I learnt in emacs, I could reuse on all the hosts I ssh into.

    On top of that - basic navigation in tmux also uses the same shortcuts. Win-win-win :)

  • I spend most of my time thinking, not writing code. I really don't care all that much about time saving, but I do concede that not taking my fingers off the home row feels really great. Other editors, even this very text input I'm writing my comment in right now, feel clunky in comparison.

    The most important part to me, however, is how customizable it is. I'm not just using (neo)vim, I'm making and using my own personal development environment. Almost every aspect, be it visual, keybinding, system integration or behavior, is changed as I go to suit my needs above all else. I think the only way to go even further with this would be switching to Emacs :^) lisp machines are no joke.

    It's not necessarily mechanically faster—though it absolutely can be: sometimes I get my editor state to where I wanted so naturally and so quickly that I actually pause for a moment after to ponder, wait, how the hell did I do that?—but darn do I like spending time in it, and it just keeps getting better. In a way, that actually makes me more productive: I'm a happier dev.

    In the end, it's all about you. If you are at your best in vscode or sublime or whatever, keep at it. My only suggestion is: if you're willing to put in the time and effort, consider trying to make whatever you use truly yours.

  • I don't think I like vim or similar for the "productivity gain". It just feels much more smooth of an experience when I don't have to target, point at something visually and click all the time. Or move my hand to a 4 keys that are as far from my hands resting position as possible. I don't believe I have saved much time. But I had a blast working with it and want to continue this serendipity experience for the rest of my time.

71 comments