Vim is touch-typing on steroids

It also has the convenience of being a fairly common set of keybindings in editors nowadays, as many have an extension that gives Vim keybindings without having to go all-in on a CLI-style Vim editor.

If purely going off programming speed, probably won't improve much. Most of the time is spent thinking. But it helps reduce annoyance in many other situations - I'm not annoyed when I think, but I'm annoyed when I have to move the cursor, drag it and do it 10 different times when in vim the same is burned into muscle memory and can be done without any thought process, over some config file that I must edit now but not that often enough that it's worth creating a script or template, and then the same apply to templates as well and all levels of abstraction.

An extremely common scenario is to copy the content from one enclosed parentheses and into another, and similar class of problems. With vim it's just a few keystrokes, but without it's lots of cursor and drag. These common scenarios are why people use vim bindings.

Oh and I can do all of that in the terminal of a remote machine, which happen to have enough memory to run a massive integration test, and build all things a lot faster.

The point of using Vim, is that you boost your keyboard interface to the maximum. Obviously, using Vim, means you touch-type. Also, you don't use the mouse. Basically, using Vim, is like having the brain hard-wired to the computer for every task, not only text edition. Everything you do goes through the keyboard, and you don't have to think about it. You scroll through text, search for it, edit it, open new files, etc.

For instance, most of the time I don't use any GUI for Git either. I do everything in the terminal, and only use the GUI for partial commit (ie. select which line to commit). I have dedicated aliases for getting history, etc.

Also, when learning Vim, you notice that many (Linux) tools have Vim shortcuts enabled. I discovered many of them by chance, out of the habits of using Vim shortcuts.

Manipulation far outweighs input. And manipulation is fundamentally thinking, at least for me.

So basically it's jumping around, refactor some stuff, and add some stuff. For that, Vim is ideal.

Code only flows straight from brain to fingers when it's trivial and boring ;).

I use the VSVim plugin in VSCode. I wouldn't necessarily call it a "productivity boost", but more of a convenience or ergonomic solution.

The Vim keybindings make it really easy to for example copy something within () and then navigate quickly and paste it somewhere without touching your mouse.

But overall I agree, I can probably do the same amount of work without the Vim plugin, it would just make it more inconvenient: more mouse manipulations, ctrl-shift-arrow finger spreadstands to select chucks of text etc.

There were people at the company who were more efficient than me using Sublime + mouse, but I was less efficient using Sublime.

(but really the biggest reason I use vim as a slow and sloppy typer and not a computer person is, hotkeys make my hands hurt, I've managed to avoid any RSI or pains like this, and I like vim better than vim keybindings in other editors.)

other productivity gains not related to typing were the search/replace in vim, embedded terminal, and being in and staying in a terminal made it easier and quicker to switch to scripty things, searching or reformatting files etc

When I edit existing text (program code, prose) a modal editor shines. I am mostly in command mode and re-arrange text or re-factor code from here to there.

When I am _creating_ text, for me a modal type editor is a hindrance. Agreed, I should probably be most of the time in insert mode yet in practice I find myself switching between insert mode and command mode all the time. For what reasons ever this switching never made it into "muscle memory" and disrupts my workflow.

For that reasons I am an avid user of both Vim and Emacs.

I am very bad at keeping all that stuff in my head at once. I need to get things out of my head onto the screen as fast as possible, so that I can then think about the "next step". Then I need to be able to quickly refer back to many places quickly and switch back and forth between different places in the codebase.

For example, as soon as I think of a corner case, I'll try to handle it immediately in an if statement or something. Then it's there, in the code. Maybe it stays in the final version, maybe I end up with 10 if statements and need to refactor everything.

But it's much easier for me to do that when everything is written down in the code rather than trying to do it all in my head.

If I typed at 15 WPM, I'd probably be easier to just reason about it in my head, because by the time I finished typing, I would have forgotten what I was thinking about.

I'm sure these things cause a feedback loop of sorts. Because I know I can get stuff out of my head quickly, I don't bother training myself to get better at storing more in my head at once. So I get worse and the solution is just to edit text faster.

Similarly, I suspect since you can keep everything in your head, there's no incentive to get faster at editing text. And if a problem is "harder" the solution is to get better at keeping stuff in your head.

I don't think there is a right or wrong answer. I think exposing people to both sides is important, so they can find what works for them.

I agree with you about code entry speed, that's not the point.

I think the easiest way to put it is that vim is 0% task loading. I never have to expend any energy dealing with it, making it do something I want, finding some button that moved around, etc. Vim just works: in almost two decades, I have never once encountered a single bug or change in behavior that I found irritating. Seriously, never. I just write code.

99% of the code I have written both personally and professionally in my lifetime was written in vim. That's the other win for me: all that muscle memory is still beneficial, now and forever. Its a much more universal tool than any IDE.

For simple things, there's no perceived bottleneck in any editor… but not everything is simple. The productivity gains come from being able to make complex changes to documents using just normal mode and ex commands, which would normally require macros, scripts or plugins in other editors.

For example, this 12 year-old video by Derek Wyatt [1] demonstrates extracting the text from a XML representation of a mind map and turning it into a hierarchical, bulleted list using Vim’s search and replace commands which support regular expressions. Attempting to do the same thing in Notepad for example might take you 15-20 minutes.

He has a series of these videos, some of them jaw-dropping showing the power and brevity of using Vim for non-trivial editing and data extraction tasks.

And remember—this is Vim from 12 years ago with zero plugins.

> Does code just flow from their brains into their fingers? I don't get it.

There's a reason why the subtitle for Drew Neil's book Practical Vim is "Edit Text at the Speed of Thought" [2]. It's probably the best book on Vim that illuminates the power and efficiency of Vim and why it matters.

One you attain a level of proficiency with Vim, as you think about what to do next, your fingers hit the right keys and without thinking about it, the change is done.

An identifier for a constant needs to be all caps? Say the cursor is at the end of the line and the identifier is at the start of the line and I'm in insert mode.

1. Press Escape (enters normal mode)

2. Press '0' (motion for jump to first character of the line)

3. Press control-v (enter visual block mode)

4. Press 'e' (move the cursor to the end of the word while highlighting the word)

5. Press '~' (switches the case of the highlighted characters)

There's no reaching for the mouse or moving your hand towards the trackpad from the keyboard. It may not seem like much, but for experienced Vim users, an operation like this is a second nature, muscle memory thing that takes about a second to do. There's no break in focus or concentration and you're off doing the next thing.

That's where you save time and editing becomes more efficient. And while there are dozens of these types of simple edits that second nature to Vim users, doing more sophisticated changes can be just as efficient.

[1]: https://vimeo.com/user1690209

[2]: https://pragprog.com/titles/dnvim2/practical-vim-second-edit...

All that typing in 20s finally caught up and I have been having recurring wrist pain.

Keeping fingers near the home row as Vim keybindings encourage and avoiding jumping around on keyboard in one way to avoid wrist strains and something I'd recommend people to start doing earlier rather that later.

Editing text using Vim, once you've built the muscle memory, really feels super natural and effortless. I really hate reaching for the mouse; it just irks me in a way that's hard to describe. Similarly, editing code without Vim feels tedious in a similar way. Imagine scrolling a long article by pressing the down arrow over and over, or clicking the down button at the bottom of the scroll bar.

Another complaint I see is that remembering the commands is too hard an ask. I moved from QWERTY to Workman at the same time that I was learning Vim and it was interesting because I learned that I -- and probably most people, but I'm speculating -- don't associate commands or actions with letters after they're initially learned. It's all muscle memory, just particular movements of select fingers. The Vim stuff you use day-in-day-out just sticks in your brain and you don't think about anymore than you think about which fingers to activate to type words.

Of course, some people probably just prefer to edit text like they do in almost all other text-editing contexts. They can already edit text; without some kind of perceived extra value, there's no motivation to change, or seemingly even try to understand an alternative. For me, it's the pleasure of feeling efficient and doing dev pain-free.

That's very off from my work. For me, it's the opposite: 95% is writing code, navigating code, testing code or doing stuff in the shell. Reading documentation usually makes only a small amount. And even then, writing notes makes a good part of it too.

> conceptualize what I want to happen, and construct the corresponding logic flow, while trying to anticipate potential problems and corner cases.

I can also do that while typing. Mindgears are no reason to stop typing.

It's an Amdahl's law thing. Even if you drop my typing time down to zero, it wouldn't affect much. That said, multiplying my typing time by 10 would be a hit.

I consider being bottlenecked on my raw ability to type to be a huge red flag. I'm doing something wrong unless I have a very specific reason to be so bottlenecked, like I'm momentarily just doing data entry with no ability to simplify the process. (Unusual, but it does happen; for a micro example, typing out all of some enumeration's value can bottleneck on raw typing speed if there's more than a couple of them and I happen to be able to instantly and correctly name them all.) Must be missing an abstraction or something.

No, but the benefit is in the mindset encouraged by Vim, especially around modal editing.

Honestly, it does feel that way sometimes. You move so much faster and with so much more efficiency and power that you can just think at a higher level while you're coding.

In my case, this often creates an elegant and conceptual code that doesn’t match expectations or even reality. Reminds me these meetings when someone e.g. says “no-brainer, there’s API for that” and goes on with requirements, schedules and administrative tasks without checking first if it’s hooks, streaming, polling with a rate limiter, or a non-idempotent email-like protocol with a completely undocumented bullshit in its payload section. The correct remark is “hold your horses”.

More than half of my work (strange corners of fintech) is checking, testing, prototyping, fail-refine cycles, unrealistic expectation reports. Not only APIs, also hw, niche software, reverse engineering, a little bit of everything. 80% of it goes straight into the “Attic” repo after few hours. I have to type an unelegant and unconceptual code fast and reshape it at the speed of thought about a realtime problem, there’s no time for clever design if a business-critical decision or a paper-heavy process depend on these experiments.

Using a boring editor feels like you want to quickly visit a few places to see if they are good enough, but they are all in different cities, so you start to forget details while you drive. And relying on a documentation is like buying a house by pictures alone.

For me the structure comes from the actual code, after I can extract its true shape, after the requirements got satisfied in a fully functional prototype, which is also a sort of a knowledge base for a project. I’m able to plan it in advance, but only with 20% probability and 80% of unnecessary work.

I once believed this and this comment could have been written by me verbatim. But I decided to seriously give vim a try and I'm still very happy 8 years later. I don't know for sure that vim makes me a better programmer, but going from vim to another editor is a bit like going from your large desktop screen to a 13" laptop working at a café. I can do the work but it's just slower and not as enjoyable.

Maybe it's not so much vim specifically, although I enjoy the modal editing part, but just 100% investing in a single editor and getting really good at navigating and editing code with it. It's always fast and responsive and always available. Before vim I used different editors for different jobs, Emacs, BlueJ, Eclipse, Visual Studio, Sublime, XCode etc and I never truly invested in any of them. Once you make a decision to just use the one editor, it's a powerful thing.

Don't think of vim as a magic totem of productivity. You should think of it as a largely distraction-free editor. No messing about with a mouse. No GUI to get in the way of your thoughts. Loads up immediately, and works the same way in any system, local or remote.[ß]

So it's less to do with speed of writing, and much (much!) more about maintaining focus.

ß: not really true, any long-time user will have their own customisations they rely on, but the basic commands are always the same.

I like not having to use the mouse, that's more ergonomic for me. Some people have an ergonomic mouse, I just avoid using it. Different solution, not necessarily better or worse.

Being able to juggle text really comes into its own when you now have to move it around from one module into many, appease the linters, search-for then factor-out a common pattern, or rewrite your idea in place without breaking it. These are all things we do to take code from the “it works” stage to the “it’s correct” stage, namely self documenting modular code that is human as well as machine readable.

Vim makes light work of the back breaking chores involved with code gardening, which indeed bears little resemblance to programming.

It’s just the ergonomics and easy customizability. Keybindings are in all editors, but in vim I don’t have to press all buttons at once. Just: “space”. Walk to the coffee machine. “g”. Get interrupted. “c” - there opens my git commit window. This feels so infinitely much nicer than any other keybinding system I have used. I always struggle going back to anything else.

Next to that, the way the config just works. Just a file I can edit.

Vim doesn’t work wonders, it’s just a preference.

A friend suggested this to me a while back so I tried a couple IDEs, and it didn't really do it for me. Mostly I think this for three reasons:

1. IDEs don't offer features I need. I don't often need to do a big rename (and if I do, sed and grep have me covered) or generate getters/setters, or what have you.

2. Cool stuff happens outside IDEs. There are tools that generate docs for APIs or even APIs themselves. There are tools that generate clients for APIs. There are tools to build apps using formal techniques (think Jason Donenfeld's work on WireGuard here). IDEs are behind here.

3. For "reasons", I had to implement a circumspect version of DBT in a few days, roughly 1300 LOC. Doing this with Vim was hard enough, but doing this with an IDE would've been impossible because while they help with some of the drudgery of the structure, they can't implement a structure itself, and they can't help me wrangle the raw code.

> Does code just flow from their brains into their fingers? I don't get it.

It sounds ridiculous, but yeah, more or less. I learn and assess by doing, so mostly I jam things out at 140 wpm, see if it's good, if not do it again. And over a career of doing this I have to do things over less and less, and when I do I get both an implementation and a pretty good empirical defense of it at the end.

Even better, unlike most IDEs, the overwhelming majority of your screen is devoted to just the text. There are no toolbars, no sidebars, not even a menu bar. Vim (and similar terminal based editors) are the original focus mode text viewers/editors.

Finally, the VIM chords become natural in a way keyboard shortcuts don’t. Part of the reason is that with the VIM normal mode, you have access to significantly more keys with which to form shortcuts, whereas most other editors use number and letter keys for typing text, so shortcuts become increasingly convoluted combinations of modifier keys.

Everything about VIM is optimized for reading text, then editing text and only after that inserting text. Inserting text is a special mode in VIM, whereas the default normal mode is for reading.

So VIM is a highly optimized tool for the workflow you described.

It’s interesting you say this, since I’ve always thought of it in precisely the opposite way! A traditional editor is thoroughly imperative: all editing operations are built up by sequencing basic commands, almost exclusively ‘insert/delete a character’, ‘move to this line/column’, and ‘select from line/column position X to position Y’. By contrast, Vim gives me an entire declarative language to work with text: if I want to ‘delete a word’, or ‘change the next 10 lines’, or ‘move to the previous occurrence of the identifier under the cursor’, I can just do that, without having to mentally break it up into sequences of smaller editing operations.

I suppose this all goes to reinforce a point I’ve made several times before, which is that ‘declarativity’ is more of a continuum rather than a state. Calling something ‘declarative’ without context isn’t very helpful, but it’s entirely valid to say that most text editors are less declarative than Vim, and Vim is in turn less declarative than the refactoring operations in a full-featured IDE.

Unfortunately, I had to put it down to read the 695,378 word Vim manual.

Or at least, the 33,807 word core essentials.

Approachability is... not Vim.

Especially when both the manual and Practical Vim to absorb "how to use it" are a such a necessity.

In fact, any IDE (or any coding environment) lacking VIM bindings is broken.

As long as my computer is beefy enough, I’m perfectly happy using Jetbrains or VS Code or whatever IDE, but I always use VIM bindings and it’s been a key piece of my recovery from severe RSI. It’s been a nice productivity boost, too.

Are you the publisher or something? What a weird thing to say. I haven't read it, so I guess I'll go back to using nano--after 15 years of vim--and just suffer?

Uh, what? I find it absolutely painful to watch my coworkers click around in their IDEs. It takes them forever to get things done.

Of the handful of hard core Vim users in the office, I’m the least sophisticated. But I’m WAY faster than all the non-Vim users.

I might read it at this point and learn a lot, but I'm still happy and productive with what I do know.

Vim is wonderful but a massive waste of time and the quality of plugins is just lower jn general (obv. there are several exceptions, zig language support, for instance is much better than a lot of other vim language support plugins out of the box). The modal editing can't be beat, but frankly it's just way more painful to do sophisticated things in Vim than it is in a modern IDE. At best you need to produce a write once vimscript and hook it up to a command. Contrarily the ecosystems of modern IDEs are so large there's actually a greater chance someone already solved you problem and provides it with one click/hotkey. For me, vim is nothing but a constant distraction generator. Instead of being able to focus on what I actually intended to get done I'm ever tempted to go off writing some vimscript to solve some edge case I just encountered while editing or to automate something--much better to just make it a nonoption, at least for me. I'm sure there are vim gods out there that have an entirely different experience.

Vim is a language. To speak Vim is to speak in a way with your hands that turns words into action and moves text at the speed of thought.

I have long mastered Vim after over a decade of experience. I can barely tell you what keys I’m pressing, but when I imagine some text in my head and how I’d want to change it, I feel the force at the ends of my fingers that guides my hands until the modification is done.

Much like how you can speak to express an idea without having to think about the way your mouth moves, I can easily edit blocks of code without really knowing how my hands will move, I simply trust they will do what I need and it happens. Vim has become the interface by which my mind can directly immerse itself into the conversation of code on a screen. Most will never understand the feeling of this power unless they deliberately pursue deep mastery of Vim, but once you’ve gotten a taste of it, it becomes intoxicating.

Vim is well worth investing your time in. I guarantee it is one technology that will exist for the rest of your career. The year will be 2100, and Vim will still be around and in use by the best engineers.

Setting it up is still a nightmare, there are pre-made Neovim configs that I found helpful to start with (Nvchad, astrovim) but even then adding support for a new language is too much effort at times (as compared to VSCode where VSCode will suggest to download extensions the first time you open, say, a .go file and you just have to click)

VSCode with Vim bindings seems like a decent middle ground.

Among those I know who've complained about RSI and the like, the common trend I've noticed is how they press the keys --- very abruptly and probably with far more force than necessary.

I've been using vi for literally decades so I don't think it's to blame. I average 140-150wpm on prose and can type all day at that speed.

Having the keyboard tilted and each half far away so that my shoulders aren't rotated inward was a huge win for me.

But I guess when I was using the mouse, I wasn't "slow". I would "rapidly" switch from keyboard to mouse as fast as I could. The longer it takes me to get something from my head onto the screen, the more distracting and exhausting I find it.

Eventually there will probably be neural links, and you just think something and it happens. Until then, vim is as close as I can get it.

I started getting RSI. Not really from coding, but from mouse use in games like Quake and Half-Life. My fix was actually to start riding a bicycle, and getting in general more fit, going to the gym, etc. RSI disappeared as I got more fit. The real issue is to live a sedentary life without enough bit muscles movements.

I've seen many coworkers(me included) switch from vim to IDEs, but still use it here and there. I think vim alone makes less sense in our current environments where we're constantly interfacing with many different systems: In my case I need SCM status, a command prompt at any time, docker container status and commands, quick local to remote file transfer, local and remote linting (don't use the same rules) and image previewing.

I could probably make a vim + terminal setup that brings me 99% there, but it just doesn't make sense as a time investment TBH. And buttons to click are nice, really.

For hjkl I just used arrow keys since they are nicer and I dont find much difference between them.

For modes I only learned about Normal, Insert and Visual. No more than that.

You could say my Vim editing is extremely ineffective, but it is effective enough for me.

That said, if you’ve been trying vim seriously for ~15 years, maybe it just isn’t your thing.

About 5 weeks in I ceased trying to make Java work with vim and have been using intellij (with vim binding) for Java and Kotlin. But kept using vim for everything else, which is roughly 50% of work load and stretches several different language and config formats.

Have been using vim ever since, the cliff is the hardest part, but it was totally worth it.

Despite that I willed myself to continue using vim because of the plethora of praise it had, and the promised eternal benefits I will be blessed with, so say the evangelists.

After that it was a breath of fresh air to be able to type at the speed of thought. I would never dream of going back to non-modal editing again.

Now I'm using evil/emacs and couldn't be happier. There's another modal editing that's gaining traction called meow, and maybe other variants that I want to learn. But for now I'll stick with evil/vim-mode.

I first tried the wrong way to learn Vim: memorizing keybindings. That's not helpful at all.

Write way to learn Vim: understanding Vim "grammar" as this repo teaches.

EDIT: Also, you can use vim.keymap.set, no need for a vim command, just `vim.keymap.set("n", "<c-c>", "<cmd>set hlsearch!<CR>", {silent = true})`

The modes are what makes editing in Vim efficient.. you don't think Vim users are out here swapping through modes looking for the one that lets them paste a line do you?

For me, the other big advantages are staying on the home row as much as possible and reducing chord shortcuts. I used to use Emacs but pain in my left wrist led me to search for a way of editing code without Mod+Key on one hand. I have some custom keymaps in vim that allow me to move to the start/end of a line with Shift+H and Shift+L, move up/down code blocks with Shift+K and Shift+J, and page up/down with Ctrl+K and Ctrl+J. In most standard editors, I find moving my right hand to the arrow keys and home/end to be unreasonably slow and error-prone in comparison.

That said, I'm not an evangelist. I don't care what editor other people use and I'm not sentimental about vim. It's a dinosaur with a lot of legacy cruft and I would switch to something else if I could reproduce a similar setup.