I've had a TREMENDOUSLY DIFFICULT time getting fully up and running with it in terms of workflow, but the text navigation alone has absolutely made me code not necessarily faster, but in a MUCH more enjoyable way. After a while it became difficult to imagine navigating a piece of code without some of VIM's core ideas, even if in my case it is down to mostly the feature-set related to easily navigating a file.
Alas, for me then the VScode-Vim extension is doing the trick, but since you mentioned the learning wall, curious if you know any resources or can suggest a path to move past it nowadays.
- Reading through vimtutor
- Disabling my arrow key bindings and unplugging my mouse for a week (as part of a combined vim/i3/vimiuim learning experience/experiment)
- Playing Vim Adventures, a puzzle game based on Vim's controls
The three days of godawful productivity has paid off a thousandfold- especially when I later became temporarily disabled (broken bones in both arms) and couldn't use a mouse for a while.
I tried using vim on vscode, but it doesn't play well with Python utils like Black and Flake.
If you are using these modern tools you are buying into the whole experience.
Playing editor golf has really gotten out of fashion these days.
Then suddenly, a skyscraper shoots up in what seems like no time at all.
Too many people want the penthouse without committing the required time to dig deep into the Earth and pour a solid foundation.
It almost never works.
There may be a subset of editors where this can be true, but definitely not “any other editor”.
But that’s not what Vim is (only) about. Editing text with Vim a pleasurable experience unlike any other. See the parent’s comment on that as well.
It is, however, the steepest wall I’ve had to climb usability wise. Probably akin to Blender, where everything is different from what you would expect at first, but, hopefully, for a good reason.
If you are only developing software, vim isn't the best program for the job. By default, it is missing important features of an IDE. Customizing it to fill those gaps is difficult. Yet if you're working of different types of text files, the skills that you learn in one domain are transferrable to another domain. If you are proficient at editing documentation and data files in vim, you're probably going to prefer it for editing code since you are building upon pre-existing skills.
> But when it comes to programming, there are only so many things you can sacrifice! You can cut down on your documentation. You can cut down on commenting your code. You can cut down on email conversations and participation in online discussions, preferring group discussions and hallway conversations.
A great snippet of a Yegge article from 2008. I don't even use Vim, but your mindset seems pretty toxic and it's unlikely that your 95% is actually 95% when all of the sacrifices you have to make are taken into account.
The shortcut CTRL-W (CMD-W on Mac) could be used in IntelliJ for this. But not sure, I switched back to Vim some time ago...
Some people like to say that coding/typing speed is an insignificant portion of overall productivity, but I wonder how true that really is.
I have to use an IDE or notebook environment a lot now, but when I'm trying to make sense of a folder full of source files I always break out vim.
This is where the mouse-free operation (though modern vim has OK mouse integration) and the close relationship with bash/sh/zsh shine.