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.

I fail to see how Vim is supposed to be superior to that. It has essentially the same navigation features, with different keybindings. And the idea that those different keybindings are somehow "better" is a big [citation needed].

I only use a small subset of Vim's shortcuts - but most text editors I've used I'd imagine don't have the breadth Vim does (or they do a really poor job of documenting it). Can you point out a doc page for some IDE with similar navigation capabilities to Vim?

The whole point of widget toolkits is that the keybindings for input fields are the same everywhere. I use Linux and almost exclusively run GTK-based apps, and every text input across the whole system behaves the exact same way, with consistent keybindings for navigation, undo/redo, copy+paste etc. This is how good UI should work.

Platform conventions are important, and it's the job of individual programs to adapt to them – not the other way round. Vim fails big time in this regard. Can you make Firefox's form inputs use Vim keybindings? If not, there's your inconsistency already.

I disagree with that. And the world doesn't have to be perfect.

If you use Vim and you like it (it takes LOT of effort), you will adapt the platform to the Vim ways whenever possible. Everytime I encounter something I cannot vim-ize, I'm pissed but I have to put up with it. It's like working with Windows.

For the browser, you can use Vim binding for navigation, and edit with Vim. But again, this is not mandatory per se to benefit from Vim as a developer.

Do you mean something like this: https://github.com/glacambre/firenvim?

It's a feature, and it follows the unix philosophy. But I get that not everyone needs or wants it.

On another note, do you expect your hotkeys from your Office program to work in a Firefox form field?

Please no. My keyboards have cursor keys. I really appreciate the freedom not to have to remember if I am in insert mode or in edit mode.

And yes, many of my shortcuts involve the cursor keys and the rest of the extended keyboard keys. Also, the function keys. These keys exist for a reason.

My pinkies love me ever since I started using vim. For me it's not the specific keybindings, but the modal editing allow more uses for the same keys depending on context and less need for modifiers.

In other editors, you can learn the shortcuts, or you can just monkey around.

But it is true, and I agree, that learning how to use YOUR editor gives great dividends.

In my case, my editor is Sublime Text. I have extensions and configurations I really need, because now I am used to them. Yes, I know the commands to navigate by word, line, block of code, or even use the right side minimap (with git colors for new and edited code) to move faster through the code.

Also: some users, even here in HN, underappreciate the mouse. But every single ex-StarCraft player knows that mouse+keyboard can be ridiculously fast when being used by trained hands.

At least for me, I can select and move, or reindent, or whatever, a chunk of code much faster with the mouse than having to know how many lines it is and then typing the equivalent command.

So yes, learn touch typing, and learn how to use your editor. It matters. What doesn't matter is if your editor is vim or not.

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.

Except web browsing, which is a huge part of software engineering, and which is nearly impossible to do without the mouse because most websites cannot be reasonably navigated with shortcuts alone.

So the whole model falls apart, really.

https://github.com/tridactyl/tridactyl

Not that I know everything, but I view informational browsing as a distraction while programming. The LSP augments most of the knowledge gaps for me.

If vim isn't for you that's cool. But I find other editors for me are this-is-fine.gif.

Really, the model doesn't fall apart. But you don't have to use it if you don't want to.

Most of my operations on a web browser involve scrolling or swapping pages, which I typically do with a keyboard. Besides every browser has keyboard extensions that allow one to select links through keyboard press. Being a neovim user I like vimium on firefox. I also like to use text based browsers for a better browsing experience and less distraction when I am coding.

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

The power of text-based manipulation is that you don't have to learn a different set of hotkeys for different types of material.

Or do the reverse — find all usages of a CSS class from its definition (again: do so reliably, it's not a simple grep).

Find all references to a particular database column (in SQL queries across the project, foreign keys in other database tables, and ORM models)? Same hotkey.

Stuff like code selection works reliably since IDE work with code on an AST level and you're asking it to select the current AST node (and not the "current text block"), going up the tree as needed.

And so on.

And the weakness of text-based manipulation is that it views code as characters rather than as semantic data.

Modern IDEs either have their own semantic code operations, or use language servers to actually understand the code rather than just work with character strings. This is vastly more reliable when doing refactoring or project-wide navigation. Text-based approaches are a crude hack by comparison.

Ctrl/CMD + Y vs r

There’s a significant difference in speed. But more importantly, the former requires RSI inducing finger gymnastics, whereas the latter is a tap of a fingertip.

The much faster speed but more importantly less complicated chords/key taps in VIM, leads to a qualitatively different editing/reading experience.

For example, I once read an economics book that characterized computers as lowering the cost of integer arithmetic by an extreme amount. That led to things like digital music/pictures - no-one would have previously thought of using a ton of numbers to represent a song - not just efficiency gains in accounting.

Music has long been represented using math and math concepts. Musical notation is a cartesian plane with time on the x-axis and pitch on the y. But that's the representation, and it's not about the representation, it's the ability to manipulate at extremely high speed.

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

Any widely used modern editor/IDE will have plugins to do the same thing.

> having some custom scripts that read ctags and could tab-complete keywords from our large codebase

Contextual completion as offered by modern IDEs or language servers is vastly superior to Ctags, and you don't have to home-cook anything to get it working.

> and having the same editor on our embedded servers and VMs as on dev machines

That's what SSHFS is for. No need to limit yourself to whatever happens to be installed on the remote machine. You don't even have to copy config files around.

(sshfs is not a direct substitute for being able to quickly interact with a remote environment)

> having some custom scripts that read ctags and could tab-complete keywords from our large codebase

for clarity i meant that I had a completion in the terminal when not in the editor to quickly jump to a tag in a file. `vim -t <keyword>`. i could be in a terminal, execute a remote command on a machine, know what I wanted to look at next and quickly go there without much effort. And again, other people were productive without doing this. these were just my tools and i liked them.

Contextual completion as offered by modern IDEs or language servers is vastly superior to Ctags, and you don't have to home-cook anything to get it working. > Also available in vim and doesnt need any home-cook solution. There are decent plugins that work out of the box for that kind of stuff

That's what SSHFS is for. No need to limit yourself to whatever happens to be installed on the remote machine. You don't even have to copy config files around. > or more easily: just edit remote files directly via scp/ssh. Vim can do that.

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...

The respect for vim and especially vim keybindings is definitely there, I use it for editing bashrc‘s or similar or inspecting stuff in the terminal, but what do you recommend to get over the hump of learning it better such that e.g. vimbindings in vscode could replace the standard?

For code, I use vscode currently, so your example would be:

* cmd capslock h (to go to the beginning of the line) * alt capslock l (to move right to the first word and off the whitespace) * cmd d (to highlight the word und the cursor) * F2 to rename the symbol codebase-wide or cmd shift g to select all occurrences in the file * retype the word in allcaps (enter if F2 was used)

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 and understand. For me, it's the pleasure of feeling efficient and doing dev pain-free.

When not using vim you often need control characters on the left hand. Ctrl-C Ctrl-V Ctrl-X Ctrl-A are all on the left. Also, for bash, Ctrl-R and Ctrl-E. I've been training myself to use the right ctrl key for all these, because for some reason I was chording with the left hand.

I've also tried to learn to use caps lock for all-caps, but with less success.

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.