51–60 of 93 posts
There's nothing inherently virtuous about using vim keybindings to edit vs standard OS keybindings. It won't make you a better programmer.
The real value is it lets you live in the terminal (and become more proficient at the command line as an extension). If you're living in a Java world, most things are done with GUIs and IDEs.
Yes definitely. Vim will be around for the rest of your career, long after VSCode or other IDE's have come and gone. Investing in tools and workflows that are properly open source, and have serious longevity has a big payoff.
Maybe... but OTOH, the IDEs that come after VSCode will still follow the UI guidelines that have been established for GUI tools during the last ~40 years, e.g. having menus where you can find out which functions are available, and then memorize the shortcuts for the functions you use most often, rather than having to learn everything "up front" before being able to become productive. I suspect one reason for the long…
I'm not particularly worried about switching to the next one someday nor do I feel like I'm missing out for taking 15m longer per year for the rare server editing of files compared to if I had spent 100+ hours learning vim.
There are some die-hards who refuse to take their fingers off the home row to do anything, but in reality the milliseconds you might shave off here and there by using hjkl instead of arrow keys, or elaborate vim commands instead of OS-native keyboard navigation, they're never going to add up to the hours you spend peering at code trying to figure out what it does, or waiting for a compile, or running unit tests, or a million other things developers do every day.
That said, I still use (and maintain) a vim extension for VSCode. I use vi/vim style navigation almost every day at work, on and off, alongside OS-native keyboard navigation and IDE-specific shortcuts. The value of knowing vi is that any time you are logged into a remote server you can just run it and know it will behave the way it always did.
My personal recommendation is learn vi "to an acceptable degree" and then stop. vi is the thing that is available everywhere. Busybox-based distros like Alpine and the BSDs don't have vim out of the box, and some container-based versions of established distros like Fedora have a very cut-down version called vim-minimal, so if you start to depend on more advanced vim features, you will be annoyed or confused when you are in an emergency situation and they aren't there.
Personally I don't think it is worth the effort to learn esoteric vim commands or trick out your install, unless you are interested in it just for the sake of learning something new. A lot of vim users will tell you it's worth the effort, but they can't really be objective because of the sunk cost of having spent so much time learning it and setting it up in the first place. My .vimrc is about 20 lines, the first of which is an exact copy of the .exrc I've been using since 1998. When vim is available, it gives me a slightly nicer experience than vanilla vi. When it isn't available, I can still do everything I need to do. And when I'm in VSCode and the muscle memory tells me to df- or JJJ, well that works too.
With more advanced stuff like macros and substitutions, tedious reorganisation/refactoring becomes much faster.
And you can slap on IDE-like features with language servers and the like. It isn't as powerful as an IDE, but it will also be much less complex. Or use a Vim plugin for your IDE and accept the tradeoff: losing Vim features for more IDE features.
It takes a while to learn the editing model and hence get a return on your investment, so keep that in mind.
Vim is basically the only editor you can safely assume to be available on any machine you’ll ever interact with. In my opinion, this fact makes it a requirement for virtually any developer to be able to confidently use vim during a production incident to, say, fix a broken config file while being connected to the machine through (multiple hops of) SSH, without any ability to use your editor of choice. Once this basic…
Windows?
TBH I don't think it's worth it. I've been using vi in various contexts for 35 years now but it's just too clunky compared to modern IDEs. Nowadays I just use a GUI, and only use vi for editing config files and the odd program on a remote system. But even that's being supplanted by editors with remote capabilities. It's absolutely worth it to learn enough basics to edit files. Beyond that, only if you really dig the…
> [I] found the "hjkl" navigation difficult That's because you're doing it wrong! Hjkl are fallbacks to move a few characters, it has only a minor advantage over arrow keys are is probably not worth the effort of re-learning how to move a cursor. I would not recommend learning that as your first vim move. Just stick to cursors for moving individual characters at first. The real magic is in going back/forward words (b…
> things like S to replace the line what is this barbaric default binding, s/S shall be bound to the indispensable vim-surround! ;) built in text objects are already nice combined with modifiers (e.g cw, ciw, caw, cW, ciW, caW), ramping it up a little bit with argument (ca, cia, daa), surround (cs"', cs([, ci", ca", viWS , dst), and indent (vii>) is stupidly powerful. Once the [verb][modifier]{object} pattern clicked…
I can relate to this. Writing code without Vim feels like punching in a dream. Make sure you're working in an environment where you're allowed to use such tools.. I'm currently not and it stinks.
i and ESC :w should also be in every programmers repertoire.
/ for search 123G for line number x d gg and G are valuable if you use vim a bit
The rest has diminishing returns unless you ssh a lot into machines without GUI.