Live data from Hacker News

Vim Language, Motions, and Modes Explained (2023)

ssp.sh

91–100 of 104 posts

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

#91
post #7

Separate from the usually mentioned benefits of Vim, it cured my RSI completely.

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.

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

#92
I mostly like Vim because it is available everywhere and in the terminal. In its default configuration it isn't the most powerful IDE, but it is vastly more powerful that any other default experience in any other text editor (IMO). It also makes it trivially easy to shell out to external tools for modifying the text, so even for a set up that isn't heavily riced you can still do a ton.

Even when I'm forced to use another IDE for work, I try to find Vim keybindings ASAP. I like that I can learn Vim motions and actions once and use them in nearly every IDE.

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

#93

Earlier quoted context omitted.

Are you using qwerty still?

I'm still using QWERTY yes, but I use US/UK keyboard layout for coding, and others for writing messages (SWE/JP for me). I realized that it didn't make much sense when I already have 3 QWERTY mappings in my head, and moving all of those 3 mappings to Dvorak / Colemak when those two are based on ergonomics pattern of the English language, when I type in 3 languages.

FWIW I also used the Swedish/English split before I completely changed my layout on a split keyboard. (I still use both US and SWE layout on laptops though.)

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

#94
Helix and Kakoune motions seem to make more intuitive sense to me, but it's unfortunate that editor support in VSCode and Zed is quite poor. I am waiting on adopting Helix as my terminal editor until the motions become more universal.

I also try LunarVim and quite liked it, but for some reason the motions didn't click, perhaps it is just a matter of practice..

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

#95
post #26

I’ve been using vim-extensions on VSCode/ Zed/ SQL Editors for a few years now and always thought I had the best of both worlds with this setup. But after switching to Cursor it seems like simply hitting tab is a lot faster than performing a vim motion in most cases and so I don’t see why people would still need Vim in 10 years time.

You can integrate AI tools into Vim too if you want.

I'd wager that in 10 years people may have moved on way from Cursor while people will still thrive with (neo)vim.

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

#96
post #23

Earlier quoted context omitted.

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.

That's such an overtly bad characterisation of Vim editing that I can't take your reply seriously.

It's --however-- the take of the article.

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

#97
post #23

Earlier quoted context omitted.

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.

The single most intuitive ah-ha moment I’ve had in Vi was the change verb. Change In : ci( means “change the text within parentheses.” Change unTil : ct& means “change the text until an ampersand.” And so on. It just makes sense. VSCode never had moments like that for me. It’s fine, sure, but it wasn’t anything special.

No, it isn't, but that's perhaps the point: it's so direct. It rarely gets in the way. Sure, some things are easier done in emacs, but that's when you just copy the text to emacs, do your thing, and copy it back.

What VSCode isn't, is elegant. I think the OP likes that very much, and VSCode has forsaken that in favor of simplicity and a kind of free-for-all extension mechanism.

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

#98
post #29

I have been using vim for 15 years. I disagree with the idea that it makes me more efficient than someone else . First, because I have friends who don't use vim and are very fast. Second because most of my time as a developer is not spent writing/editing text. No, I love vim because of its ergonomics. If I use a mouse for too long, my arm/shoulder starts hurting. Maybe I could improve the ergonomics of my mouse (havi…

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.

I have a qwerty keyboard also and all I have done to change my layout is remap caps lock to escape. Which is definitely vim relevant. I am a vim guy.

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

#99
post #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 edit…

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?

The overhead exists when a novice is trying to use Vim the way it is intended to be used in order to learn. Using insert mode to get the same behavior as non-vim and avoid normal mode is, in my opinion, bad learning practice.

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

#100
post #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…

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

It is an action. Check out what happens if you prefix it with a repetition:

   5iHello
-->

   HelloHelloHelloHelloHello
Same goes for other ways to get into insert mode (like I, a, A, o, O), then for dual-actions that do a delete and switch to insert mode (like s, c) the repetitions apply to the delete part.
Post reply on HN