Here come the "[..] anyway I'm happy with VSCode" comments
Vim feels equivalent to a horse carrier in comparison to vscode to a modern car.
Also comes with all the downsides of a modern car (ads, random BS, blackboxes, etc...)
Vim Language, Motions, and Modes Explained (2023)
41–50 of 104 posts
Re: Vim Language, Motions, and Modes Explained (2023)
#42I 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 discomfort. It was also around the same time I started to look in to QWERTY vs Colemak vs Dvorak, although I didn't go further with that, I quickly realized that the keyboard layout of my country (Sweden), while similar to US/UK QWERTY placed brackets in absolute garbage positions that caused strain in my right hand a lot. Then also the excessive pressing of left/right arrow + moving right hand between mouse & keyboard caused further strain.
Vim alleviated that with the word/Word/sentence navigation being more spread out, and "stick to home-row" philosophy.
But there was an additional "shift of thinking": editor as a (limited) programming language. Being able to store macros, navigate depending not just on line/character but chunks such as word & sentences made me realize I could do things such as:
"In this XML/URDF file, replace all elements with the name=X with the logic Y, which might including adding/removing xml elements/attribute"
without having to use some scripting (python + parsing etc). The process of figuring that out is also interactive. Try out a bunch of commands, stitch them together as "macros" and then make macros that calls macros that use copy-paste registry.
If I stuck with Sublime, or VS Code, I don't think I would've had that epiphany. It even helped me (non-CS guy) to understand programming better.
Re: Vim Language, Motions, and Modes Explained (2023)
#43Is 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.
Re: Vim Language, Motions, and Modes Explained (2023)
#44Badly titled post. "Vim Language" is usually used in reference to the "VimL" scripting engine inside Vim.
Re: Vim Language, Motions, and Modes Explained (2023)
#45I 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…
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.
Re: Vim Language, Motions, and Modes Explained (2023)
#46I 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…
You can absolutely change the keybindings, vim is programmable.
Exactly. See .vimrc.
Re: Vim Language, Motions, and Modes Explained (2023)
#47Here 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.
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.
Re: Vim Language, Motions, and Modes Explained (2023)
#48Is 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.
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.
Re: Vim Language, Motions, and Modes Explained (2023)
#49Yes, 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? Beca…
> 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.
Re: Vim Language, Motions, and Modes Explained (2023)
#50I'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…
> 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.