When I "program", 95% of what I do is read documentation and other technical resources, conceptualize what I want to happen, and construct the corresponding logic flow, while trying to anticipate potential problems and corner cases. In other words, most of what I do doesn't involve touching the keyboard at all.

If Vim magically tripled the speed at which I'm able to edit text, I doubt it would have a noticeable impact on my overall productivity. In fact, even if you gave me a brain-computer interface that allowed me to manipulate text at the speed of thought, it wouldn't matter much. I touch-type at around 70 WPM, which is very average, but if I two-finger typed at 15 WPM instead I would still be able to produce exactly as much code as I do today.

Simply put, text manipulation is not at all a productivity bottleneck for me. I need much more time for thinking about code than I need for writing it.

Is this really unusual? How do people operate for whom Vim gives a productivity boost? Does code just flow from their brains into their fingers? I don't get it.

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

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.

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.

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.

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

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

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.

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?

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

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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)

Vim is a text editor, not a code editor, and I keep forgetting how weird it is. "Ctrl-X Ctrl-D completes a C preprocessor macro by default" - there is no reason this should be in the core of any editor.

And finally, whatever you think of Vim, it's not worth using unless you've read Practical Vim. Without the knowledge of that book, you're too limited to approach efficient (imperative) editing.

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 argue the opposite. Because vim is such a constrained environment, the UX is extremely unified.

An IDE with vim mode is the opposite. Vim mode usually only works in the text buffers and nowhere else (at least not properly). You need to memorize a combination of vim hotkeys and regular ide hotkeys OR spend a long time messing around with your IDE hotkeys (probably comparable to vim config).

In vim, since everything is a buffer and a window, you can use your regular navigation hotkeys to move between them. I just think "I want to shift my focus to the window on the left" and it doesn't matter if the window on the left is a text file or some plugin.

In something like IntelliJ, you can't "just go left". You need to know what the hotkey is for the panel on the left. The "non-modern" UI, which constrains vim actually makes a significantly more unified experience.

> terminal in the ide so you can still run commands easily (typically better than vims term window does)

This is a perfect example. How do you switch back and forth between your terminal and text file in an IDE? How do you copy paste between your terminal and text file? Can you use vim movement in your terminal that you opened in your IDE? Or your registers? In vim, that all works perfectly just like you'd expect without learning anything new, it just works like regular vim.

That being said, I still use IntelliJ if I'm writing Kotlin. The semantic analysis they can do is absolutely top notch, can't get something comparable in vim and the productivity gains out weigh my annoyance with the inconsistent UX. Something like python though? I'll probably stick with vim, jedi is good enough.

It's the 5% of vim that's unavailable (i.e. norm, macros) and 5% of needing to still click the IDE UI occasionally that reminds me that it still isn't vim.

But then again, for some language families there just isn't a choice.

I write unit tests for my personal projects - it might sounds ridiculous but it is the reason why I can grow these projects beyond the initial 12 hours of interest. Since personal project tend to be on the smaller side I usually uses typescript or python but I've never found it an issue where pure vim usage becomes an issue at scale.

It also strongly enforces separation of concern in terms of file organization. I found using vim for development to be a positive feedback loop.

e: never mind, I see Microsoft closed sourced pylance and restricted it to their products. Typical. Of course there is still pyright along with a python language server, but I guess technically not pylance any more.

F f g G jkl; ESC i r R yy p and control A and control E probably cover 90% of my cases.

However. I use a nub on my ThinkPad so I have sort of instant mouse access for location things, I mostly use jumping for inside a line

Tabs are an organized collection of windows, and you can quickly switch between them. I might organize my windows so half the screen is one buffer and on the other half, is split 3 times horizontally. Then I edit some code and realize I need to edit some other part of the codebase. I make a new tab instead of changing buffer, so I can go back to the view I setup already without having to recreate it.

Tabs are the true power of vim, I don't have that functionality in any other editor (apart from Emacs?) and I miss it constantly. Buffers aren't really a novel concept, they work the same in VS code and JetBrains IDEs.

Yeah, Emacs also lets you do that! You can achieve similar workflows via tmux or a tiling window manager as well. It's my favorite way to work! For whatever reason I've never gone down the tiling WM rabbit hole, but I use this kind of thing in Emacs and tmux all the time.

One editor that does support it, is kakoune. I forgot about it when writing my previous comment. Each instance can connect to a server, so they can all share registers/buffers/etc. Then you can use tmux or your window manager to create the layout you want.

It's very clever, I actually think it's superior to vim, as you aren't limited to organizing your views inside a single vim "main" window. You could do stuff like kak | browser | kak, and both kak instances share everything.

Unfortunately I can't get used to the kak commands so I'll probably never change. Perhaps neovim will one day implement something similar.

Vim has been my only code editor for the past 10+ years and I wish I used tabs a little better (ie, the way you describe). As it stands I have some plugins that open in a tab so they are easy to close (like gv.vim) and otherwise use my tabline as a secondary status line (it tells me my working directory and if I'm tracking a session or not).

E.g., if you want to turn,

  * a
  * b
  * c

  "a",
  "b",
  "c",

You could do it with a regex, but I just find it far more natural to list the commands: my brain is already imaging it that way: remove the bullet, add the quotes and the comma.

Good for-loop for "do this to each line". Sometimes takes a bit of back & forth to construct the command, or sometimes it's just easier to do multiple :norm's. One of the best additions to my repertoire in years.

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.

To me, it seems clear that editing an existing body of code is always imperative— you're literally manipulating the state of the text iteratively, no matter what you do! Code generation can be declarative. But you're still going to imperatively edit your declarations somewhere, in that case. :-P

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.

I've installed quite a few plugins (e.g. nerdtree, airline etc) but they are mostly cosmetic and I myself don't do much vimscript other than some basic .vimrc. But I do have most of the content of any vim cheatsheet burned into muscle memory and can come up with combination of them on the fly. I also use :norm extensively when I need to quickly batch edit anything.

I never really did encounter scenarios where the logic are so complex that I'd rather write vimscript to solve it - at worst, I'd do a macro, but combination of modal keys are usually enough. I think I find a sweet spot between using vim to its maximum utility and less about using vim for the sake of vim.

I have a quick install script for everything I depend on and one thing I found extremely valuable is the ability to pull, install and have the same editor customized and familiar in any computer, virtual or real, it even works on Windows (WSL).

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.

Not a fact. You just prefer vim bindings, which is fine. Other people prefer other schemes, which is also fine.

I'm all for IDEs supporting many different bindings, but lacking VIM bindings is an accessibility issue and shuts out a significant % of the possible users.

I understand that XCode Vim mode is lacking a lot of the functionality of Vim, coming nowhere close to even the free XVim plugin. But you think they could at least make sure the few features they do include aren't completely broken.

But also, some Vi emulation modes are much, much more complete than others.

You're saying I don't know vim well enough. What important vim features (which I'd use if I knew vim) is IntelliJ missing?

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?

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.

I'm honestly shocked at how fantastic Helix is and it makes me wonder if all the toil of inheriting vim was worth it for the neovim project.

Something like a readymade nvim config should ideally be able to provide similar experience but it's hard to not get caught up in the the quest to get it _just right_

Plus Vim keybindings are widely available in popular editors/IDEs but I think Helix bindings will take a while to get there.

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

I've been trying to spend more time in vim since last year because I can imagine a world with the benefits you describe, and I want to put in the long-run investment to get there. But at the same time, Vim naturally lacks the feature set of an IDE, and setting up a bunch of plug-ins so that they all work together is somewhat time consuming and brittle.

I've been wondering if I should stick to Jetbrains/VS Code and use Vim as a text manipulation language, and whether I'd still attain that editing fluency you describe.

I find vim with the right plugins is as capable as any IDE, you can at least have the basics like autocomplete and various syntax highlighters and linters. Personally I think developers who lean heavily on the IDE features of more common tools are using it as a crutch for not knowing the codebase very well or language features.

Part of the journey to vim mastery is the configuration of vim until it fits you like a glove, once you’ve configured it well you rarely need to touch the config files again.

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.

Some good blog posts and some videos did it for me. I had enough knowledge to make diving into the docs more meaningful.

Besides once you understand the language of Vim, it’s not hard to make strives.

Vim was my primary editor for a bunch of years, and it's definitely fast and helps to utilize keyboard commands to the maximum extent. That's also the years I started getting RSI, changed a lot of habits, keyboards, postures etc. to come to the conclusion that the real issue was plainly doing the same movements over and over.

As a data point of n=1, optimizing workflows for maximal productivity meant doing the same optimized actions again and again, and do them fast. Which wasn't good. Reducing "productivity" and introducing more input methods that I can switch to here and there when I feel like it helped a lot. So less touch typing marathons, less shortcuts, more GUI and more variety overall.

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.

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.

Stopped using it and switch to a low profile chiclet keyboard where I was using way less strength, and could type more loosely. It also made it way easier to type on glass, as an unintended side effect.

Switching to a trackpad also helped in interesting ways, as I got rid of many keyboard shortcuts for page navigation, app switching etc. and moved to gestures instead.

To note, I still use vim a lot. Just not as my main editor. Also the changes I made are probably very personal and wouldn't have the same effect on other people with different tendencies.

Thought they really ought to just let you do this out of the box already. macOS lets you map modifier keys to other functions just in the regular old system settings.

[1] https://learn.microsoft.com/en-us/sysinternals/downloads/ctr...

I use keyboards with extra keys so the esc key was always mapped pretty near. With IME languages an ESC+language switch shortcuts is absolutely needed anyway (at least for vim users)

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 been using (neo)vim for years, and don't want to use anything else. It isn't just about productivity (I would probably be as productive in an IDE). It's because its _mine_. It's a highly customized environment, catered to my needs.

[1] https://www.youtube.com/watch?v=QMVIJhC9Veg&

Between hjkl, w, l, d, dd, esc, :command, and more modes I feel like I'll never grok vim.

After how many years do I throw in the towel and just stick with VS Code? Been at it since 2008 in some form or another :(

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.

If I wanted to erase a word in a sentence, which had seven letters, initially I might type x eight times (erase the word and a space). Then as I learned more vi I might type 7x. As I learned more vi I might type dw.

You can get a lot of navigation and editing done just knowing a few commands in vi. If you use it a lot, you can learn more commands and have an easier time.

About 7-8 years ago the standard IDE for my programming niche changed, and I had to learn a new IDE and what I knew of the old IDE I have almost never used since. The vi stuff I learned 30 years ago I am still using.

The point of hjkl is to keep your fingers in the home row of your keyboard. This is generally accepted to be good typing practice as it improves speed.

You might get some benefit to speed if you keep your hands on the home row, or you might not. This is mostly something people have been repeating as gospel, but I'm not aware of anyone testing it.

Intuitively, using the arrow keys to move the cursor without inserting a character should be faster. Assuming one is moving around the text while editing, it takes at least three keypresses to use hjkl to move the cursor without inserting a character: one to switch to command mode, one to move the cursor, and one to switch back to insert mode. That's because hjkl in insert mode simply insert their respective letters. By contrast, using the arrow keys to move the cursor without inserting a character needs one keypress: to press an arrow key.

Even if you count moving your hand to the arrow keys and back as two distinct "operations", and each keypress as a single operation, it takes at least three operations to use the arrow keys (i.e. as many as using hjkl): one to move a hand to the arrow keys, one to press a key, and one to move the hand back. Assuming that each operation takes constant time, that means that, at best, there is no advantage over keeping your hands at the home row and moving the cursor with hjkl, than using the arrow keys.

So that idea, that it's faster to keep one's hands in the home row, must be a superstition.

Incidentally, I've been using vim continuously since 2011. These days at work I use a Spanish QWERTY keyboard, but with an English Euro layout. I got the Spanish keyboard by mistake and it was simpler to keep using it with the layout I know, and benefit from more than a decade of muscle memory, than to try and learn the new key positions (and combinations). This is another reason why I am skeptical of the claim about the home row: muscle memory is faster than any spatial optimisation you may think of, or, rather, if you've already learned to move your hands one way and can do it fast, changing to a new way will slow you down, first. And then we're talking about long-term gains of maybe a few milliseconds in the long term in this case. That sounds pointless.

The keys are positioned differently, and that helps me with muscle memory.

The fact they are not in a row is a feature.

Of course, I am also a touch typist and I wrote this entire comment without looking at the keyboard or making a single mistake.

It definitely worked for me. YMMV

Don't toss it till you try it.

It is for this exact reason I am using vim in VSCode. I get some speed up in vim vs mastering VSCode shortcuts, but not enough that would make me switch. However, with vim I hardly need to move my arm over to use arrow keys or mouse, which makes it much easier on my hands and my arm.

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.

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

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.

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

To clarify and to be fair to vim, it's a few days to a little over a week of effort every 8 months to two years or so. I'll get the bug to ascend in my coding speed after reading an article like this one, check to see if I still have .vimrc from the last time I tried to configure it for things like syntax highlighting, spaces instead of tabs, etc., then give it a roll.

Vim has the best interface, but it's built on a pretty awful program. Emacs is a pretty awful interface built on a pretty great program. Combine the two!

The pattern nowadays for me always goes like this:

    1. Let me try Vim again. I do miss that kind of efficiency
    2. This is so fun, I really missed it (for a few minutes or hours)
    3. And then *one little comfort* from VSCode is missing... and I'm back on VSCode for months.

I am sure it would be some revolutionary tool, but I have no use for it other than using vi when I ssh into somewhere for few minutes once in a blue moon. This realisation has been very useful. In the past I kept trying to “get” vim. On the other hand a lot of people I know like vim as a “hobby”. Yes, liking vim and doing vim thingies is the hobby.

    vim.keymap.set("n", "<leader>sr", ":%s//")

I also added the following to remove the highlights that appear (e.g., when pressing *):

    vim.cmd("nnoremap <silent> <c-c> :nohl<CR><C-l>")

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})`

On the one hand I want to significantly increase how fast I can manipulate and edit text without reaching for my mouse, a state which many commentors here seem to have attained.

On the other, I miss the way that a Jetbrains IDE cohesively integrates a lot of features with non-conflicting hotkeys, without requiring me to fiddle around with a vimrc - great code analysis, Git, database schemas, etc.

I'm tempted by the promise of a plugin like IdeaVIM, which seems like it's 90% of the experience - but that'd still sacrifice the easy integration with my terminal setup, fzf, being able to switch between panes with my keyboard, etc. Does getting 90% of the way to being keyboard-free really give you 90% of the benefits?

Any tips appreciated :)

Vim isn't the only editor with shortcuts. Many of the IDEs listed come with pretty of shortcuts and you can configure more if you want. Those editors also let you use shortcuts without having to switch through different modes making you more efficient.

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.

None of this requires a separate mode to do. Modifier keys have been shown to be enough to give commands for doing operations other than inserting characters.

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?

I don't do anything particularly sophisticated with it; recording macros to repeat the same transformation on multiple lines is about my limit. But I love being able to work with my hands permanently on the home row of the keyboard, and having to switch between keyboard and mouse with other software feels like a chore now.

Sadly these days I mostly make Mulesoft applications using Anypoint Studio. I still use it for most of my text editing at home at least.