Live data from Hacker News

Vim Language, Motions, and Modes Explained (2023)

ssp.sh

11–20 of 104 posts

Re: Vim Language, Motions, and Modes Explained (2023)

#11

I've tried Vi/Vim key bindings on several occasions, but just couldn't be efficient in it. It's often touted as the "superior" form that confers benefit to those who invest time to learn it, but discussions with other coders have led me to believe this is just confirmation bias by people who prefer these key bindings. There are people like myself who edit frequently while writing (even with in a single sentence or wo…

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

Re: Vim Language, Motions, and Modes Explained (2023)

#13
One thing I really appreciate about Vim is that it just opens. And I don't mean speed, I mean not getting bunch of pop-ups nagging me to do something about a configuration, extension, feedback or whatever.

I'm not going to claim Vim's defaults are usable for most people, but my god can these IDEs just shut up and let me see my code? I'll go to the settings if I want to.

Re: Vim Language, Motions, and Modes Explained (2023)

#14

I've tried Vi/Vim key bindings on several occasions, but just couldn't be efficient in it. It's often touted as the "superior" form that confers benefit to those who invest time to learn it, but discussions with other coders have led me to believe this is just confirmation bias by people who prefer these key bindings. There are people like myself who edit frequently while writing (even with in a single sentence or wo…

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.

Re: Vim Language, Motions, and Modes Explained (2023)

#16

Yesterday, I used vim motions to clean up some JMH benchmark log data to a CSV. It was genuinely so useful to be able to precisely delete and replace based on regexes. I'm sure I could have done with a graphical find and replace, but it was definitely faster via vim, especially after recording macros to automate the repetitive edits.

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.

Re: Vim Language, Motions, and Modes Explained (2023)

#17

I've tried Vi/Vim key bindings on several occasions, but just couldn't be efficient in it. It's often touted as the "superior" form that confers benefit to those who invest time to learn it, but discussions with other coders have led me to believe this is just confirmation bias by people who prefer these key bindings. There are people like myself who edit frequently while writing (even with in a single sentence or wo…

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.

Re: Vim Language, Motions, and Modes Explained (2023)

#18
post #4

It's funny to see Helix mentioned, without kakoune being mentioned. Helix is a really nifty terminal editor. It aims to be nice out-of-the-box, to have good LSP support, DAP support, and Tree-Sitter support. Compared to vim's "action motion" keybindings, Helix goes for "motion action" (which kakoune popularised). I find this is frequently more intuitive. Helix also has neat discoverability.. with pop-ups showing you…

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

Re: Vim Language, Motions, and Modes Explained (2023)

#19
Yes, it’s super handy to be able to record an Emacs macro and modify large text within seconds, something that would take me half an hour. Yes, it’s super cool to navigate text at lightning speed.

But honestly, I have seen engineers who work with the mouse to navigate, and use nano to edit text in the terminal, and IDEs from intelliJ to navigate their codebase, engineers who were 10x as productive as I was. Why? Because in the end navigating your text is not what determines engineering success. It’s convenient, yes, but that’s not the core challenge. These days devs using VS Code can be magnitudes more productive just because they focus on the things that matter.

Edit:

Don’t get me wrong. I love my (mechanical) keyboard. I hardly use the mouse. I have a shortcut for everything using Keyboard Maestro, Karabiner elements, and I use Emacs for text editing, and all of that makes me super fast using my computer. But all of that does not make you a better engineer (I am not an engineer anyway). So spending time on other qualities (being able to do research, to solve problems, to manage knowledge, to communicate well, to document well) is way more relevant for your success as an engineer.

Re: Vim Language, Motions, and Modes Explained (2023)

#20
I think an important part of the Vim workflow that I haven't seen mentioned is the fact that -at least for myself- it keeps the mind engaged during "menial" operations.

When switching from dealing with the information included in the text (typically thinking about code content) to operations of moving text around and other text logistics, I often find my mind "waiting" impatiently for my hands when using non-vim editors. In contrary, when using vim (I consider myself a mid-range user), I can somewhat remain closer to the flow.

At the same time, I still remember (albeit vaguely) a significant overhead of the Vim language before becoming acclimated.

Post reply on HN