I use vim to avoid the mouse-keyboard back and forth. I also happen to edit multiple types of file, which I find useful to have / learn only 1 editor/IDE.

I am also often, if not always, in a terminal.

Some people use vim to brag, some say it's for speed, for me it's because "it's there".

Sorry Dave, you'll need to create a project, configure the SDK and log in with your GitHub credentials before I can let you edit README.md

> can these IDEs just shut up and let me see my code?

May I interest you in some Emacs? It’s arguably much more of an IDE than Vim, but it still “just opens”. And you can bring your muscle memory with you thanks to the Evil mode.

I’m not a fan of motion-action. Most of the time in vi, all I’m doing is moving around. When you input a motion key in vi it moves you accordingly with no fanfare.

The motion-action paradigm, on the other hand, primes the editor to expect an action. In many cases this leads to multiple cursors being left in your wake, which I find really distracting.

I think this stems from a fundamental misunderstanding of the vi paradigm: the primary purpose of vi was to extend the traditional line-editor ed (which was designed for editing through a paper TTY terminal) to full-screen interactive editing on a video terminal. Since early video terminals had very low baud rates, vi needed to be very efficient at reducing screen redraw. It just so happens that this emphasis is perfectly matched to the most common editing loop: jump to a location within the file and insert/delete/replace some characters. Thus vi happens to be perfectly optimized for this editing workflow and so I believe this is the reason for its enduring popularity.

The other task which vi is strong at (but which is otherwise secondary) is editing in the large: making multiple changes to a file simultaneously. This, I believe, is the primary strength of motion-action paradigm editors. In other words, they get it backwards! Thus they can’t help but annoy me while I’m working with their constant attempts to infer large-scale edits from my simple desire to jump around the file and make small changes. They are giving me a freight train when all I want is a car.

I've been experimenting with Helix in the last month.

One thing that's slightly frustrating is the key binds are running interference in my brain with the vim keybinds. Especially the x/d swap. It might be because I still use vim keybindings in other programs, but I find I'm now also worse at vim than I was before I started helix.

The discoverability is definitely a big nice feature, I definitely use more e.g. tree-sitter motions because I can actually remember them unlike in my plugins in nvim.

I think kakoune invented motion action keybinds, but Helix is the one popularizing it.

I love helix because it is very fast, it supports everything it needs to, and the built-in help/which key. It's what I wish vim was.

Shameless self-promotion of a discussion thread I started.

https://github.com/helix-editor/helix/discussions/13399

I found Helix much easier to get into than vim because you can see and experiment with the selection before committing to an action. It's also much more familiar to users of modern software (where you generally first select an object and then apply an action).

My problem with the "action motion" keybindings is textobjects that by necessity becomes more complex or even missing. This is a big step backwards in ny opinion.

There are also plugins that shows a pop-with with available keybindings if you want.

I want to use Helix but can't until it supports running external commands.

Yes people who talk about vim being more efficient, are in my opinion, misguided. For me it's very little to do with efficiency, and much more to do with creating a more pleasant experience writing text, especially text with an exploitable structure (code).

I really enjoy precision, and that's what vim provides. It's the same reason I'd much rather play an FPS video game with a mouse and keyboard, than an analog control stick. And the same reason I hate doing anything important on a touch screen.

Vim is not about speed. It’s about efficiency (less effort) and programmability. You can do the same or more editing actions with other tools, but with Vim (and also Emacs), you can make it effortless.

> Because in the end navigating your text is not what determines engineering success. It’s convenient, yes, but that’s not the core challenge.

That's true, but it's still very helpful.

I'd argue that programming isn't the core challenge either, but it would be foolish to dismiss it entirely.

Ditto, I switched to vim after horrible pain from eMacs’s required multi finger contortions and it helped to the point rsi hasn’t been an issue for me for 20 years.

Yes. So much this. I've also always loved combining that with the macro functionality.

Except: Yesterday, I used an LLM (4o-mini-high) to do this kind of task instead and i might never go back.

I don't understand why people say there is an overhead. Press 'I' for insert mode gives you the same behavior as non-vim, so your immediately at the same efficiency. What am I missing?

I don't think anyone claims vim motions are superior in absolutes with a straight face.

I like a nearby comment that essentially says "it's not superior for everyone, it's just infinitely better for me; also it doesn't magically make anyone 100x better than the next developer".

I've seen people using IDEs and flying around massive codebases at incredible speeds, all the while they're completely mystified by even the simplest vim editing.

Me? Put me in front of an IDE and painfully witness the absolute grind: I'm a sitting duck; but in Vim I feel like my brain is plugged straight into the computer: I don't even think about my hands, code is conjured just by thinking about it.

Yes, vim is not intuitive. It doesn’t teach itself to you. It takes hard work. I bought the O’Reilly vi/vim book [1] and read it cover to cover. I practiced a lot of things and was very deliberate about it.

To me, learning vim is like learning a musical instrument. You’re not going to get there without committing to it. For many people that’s just not going to happen: they have neither the time nor the inclination/energy to do it. That’s totally fine! There are loads of other tools for people to use and they get by just fine without vim!

I think my main complaint is that there aren’t a few more tools like vim. Almost all software is designed for people to be able to pick up casually and be able to get work done at a passable level of productivity without ever reaching mastery and flow state. Tools like that (easy to use but with no real incentive for mastery) are deeply unsatisfying to me for a lot of reasons.

I guess what I’m saying here is really just a restatement of “Worse is better” [2].

[1] https://www.oreilly.com/library/view/learning-the-vi/1565924...

[2] https://en.wikipedia.org/wiki/Worse_is_better

You can absolutely change the keybindings, vim is programmable.

Are you using qwerty still?

Funny enough, I believe that there are quite a lot of tutorials and that itself is the issue. Everyone wants to make their own since they deem the others to be bad and then a new subpar tutorial is created, making it even more difficult to find the few helpful articles. This ends up becoming a vicious cycle.

In the end I find comparing vim to something like snowboarding or skateboarding intriguing. It doesn't matter how much you explain it, it won't be enough. You just have to try it out for yourself and see if you can get the hang of it. Once that initial step is done, that's when reading about all the intricacies becomes useful.

Well vim comes from a different age, but it is still completely viable today.

Because you can have a GUI and a mouse today does not mean that you should not use the vim bindings. I use vim a lot in terminal (both locally or over SSH), but I also use vim bindings in graphical IDEs. Actually, I struggle if the editor doesn't have vim bindings. VScode, IntelliJ, even Xcode has vim bindings.

> who prefer these key bindings

Which ones? Do you mean the unergonomic defaults where one of the most popular action (quitting to normal mode) is bound to one of the most inconvenient keys (Esc)? Also for editing within a word you actually don't need to switch between modes, but instead could use something like a home row cursor with a modifier to move in insert mode.

I use both Vim and Emacs, extensively, so I'd just like to share my experience with mode switching in Vim. Personally, I don't find Vim mode switching to be much of a problem while editing text. It has become muscle memory to stay in normal mode by default. After any insert-mode operation, I instinctively return to normal mode. It's just a habit at this point.

Take, for example, writing a for loop. I might type:

  for (int

Then, say, I pause briefly to think about the variable name. If you happened to look over my shoulder at that moment, you would find me in normal mode. Even if I only pause for a second, I reflexively return to normal mode the moment I stop typing.

Because of that, I don't really treat insert mode as a separate "place" in my mind. Let's say I want to insert the text "abc". I don't think, enter insert mode, type "abc", then return to normal mode. I just see it as a single action in normal mode that includes the key sequence "i a b c ESC".

Or say, I want to open a new line above and insert "xyz". Again, I think of it as a single operation in normal mode that includes the key sequence "shift+o x y z ESC".

This applies to all insert-mode operations for me. Normal mode feels like "home" and insert mode is just an editing phase I dip into when I need and exit. That's why it doesn't feel like I am constantly switching modes (even though I am).

   i for (int foo; foo < 42; foo++) ESC :?foo nnn cw

I don’t know I edit a lot but I also really like vim motion. It gets really natural at some point. The mix of b and e to move around, using cw or ce to remove and start editing then getting back to moving around. Plus a lot of edit actually happens straight from normal mode (case correction, one character changes, short deletion).

You don’t really think about the modes because things flow naturally. It might also be due to the fact that I nearly never actually switch conscientiously into a mode. I always do actions which send me in insert (like c and o, very rarely I or A) and revert back to normal when done.

Plus vim has the advantage of making things like just remove everything between these symbols and set me in edit there very easy which is something I miss when I don’t have vim bindings.

I don't think it's the keybindings in particular that people love about vim, you can rebind everything after all. I'm attached to vim keybindings in the same way I'm attached to qwerty keyboards - something had to be the default, it's fairly arbitrary, and there's very marginal benefits in switching to a different set of bindings.

It really is the modal editing style that's the main draw. Someone who edits frequently should find vim more convenient, not less, but it does require a lot of time to learn all the available commands and burn them into your muscle memory.

> There are people like myself who edit frequently while writing (even with in a single sentence or word), so this switching between normal and insert modes to do chunks of each operation at a time incurs a heavy cost.

I edit this way too and there's no heavy cost here. Well, maybe when you're first learning and switching hasn't become second nature, but when you do it's not something you even notice.

I've grown up on vi and later emacs, but VSCode is no joke. It does almost everything, and most of it better, and more intuitively. There's no reason to torture yourself with counting characters, words or lines in order to get the delete command correct in one go.

Vim feels equivalent to a horse carrier in comparison to vscode to a modern car.

I feel like those trying to teach me Vim are the same who refused to learn to use VsCode.

Once configured, I can do the same than Vim. With more features.

Technical moncultures are bad. The VSCode people ought to at least tolerate VSCode refuseniks as a kind of endangered species, worth keeping around out of a mixture of sentiment and insurance against memetic stagnation