Live data from Hacker News

Vim Language, Motions, and Modes Explained (2023)

ssp.sh

61–70 of 104 posts

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

#61
post #43

Is not vim a tool from an age of very much different terminals to what we have today, with different limitations that are no longer actual? Yearly(!) emergence of new tutorials trying to finally explain how to navigate with vim is a consequence of this disconnect.

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.

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

#62

I use vim & vim bindings for most editors I have (VS Code, Obsidian) and I think there's one thing always missed in this conversation (at least on HN): The changes that happens in your thinking when you start using a tool. Instead we get stuck on pros/cons of tool A vs tool B. I got in to vim in college for two reasons (the real) one was just that I wanted to look cool, and the second one was to relive my hands of di…

Are you using qwerty still?

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

#63
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?

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

#64

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.

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

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

#65
post #37

I tried vim motions as a daily driver many times but, I don't think that with today's expansive IDEs vim motions are all that superior. IDEs have very competent shortcuts and features built in. My biggest problems with vim are lack of feature discoverability and the fact that you can't change the keybindings. It's very hard to learn new things in Vim without specifically googling for them. It's highly likely that if…

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/en…

This “worse is better” is very interesting. Are you suggesting vi/vim is an example of “the right thing”, vs a “New Jersey” style?

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

#66
post #23

Here come the "[..] anyway I'm happy with VSCode" comments

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.

> There's no reason to torture yourself with counting characters, words or lines in order to get the delete command correct in one go

No one proficient in vim does this. Just use relative line line numbers or delete words in full with ciw.

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

#67

I use vim & vim bindings for most editors I have (VS Code, Obsidian) and I think there's one thing always missed in this conversation (at least on HN): The changes that happens in your thinking when you start using a tool. Instead we get stuck on pros/cons of tool A vs tool B. I got in to vim in college for two reasons (the real) one was just that I wanted to look cool, and the second one was to relive my hands of di…

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.

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

#68
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…

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

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

#69
post #11

Earlier quoted context omitted.

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…

I think one (often forgotten) good advice to get used to the mode-switching is to move the ESC key to Capslock on the keyboard. It's tedious to learn to always go to the ESC key, upper left of the keyboard. Capslock is available from home row, and you should probably not use CAPSLOCK anyway, it's a bad practice. Put ESC key there instead and vim becomes wayyyyyyyy more ergonomic.

I map 'jk' in Insert mode to . In Insert mode, it takes me out to Normal mode. If I'm already in Normal mode, it simply moves down a line and right back up. This habit is so burned into my muscle memory that I often end up typing 'jk' into non-Vim input areas (like this HN comment box).jk

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

#70

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…

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

Post reply on HN