Vim Language, Motions, and Modes Explained (2023)

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

Do you modify your keyboard layout at all? I’ve tried Vim several times and many of the motions just feel awkward as hell for my fingers, but I’m on a standard wasd keyboard.

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

This is such a big pro imo. Gone are those days when my hands/wrists used to be in pain from all the typing. Vim removed all that pain and made me look forward to typing as a fun activity. God bless Bram.

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.