it's pretty crazy that this article only mention hyper or the built in vs code terminal as it's two recommendations, when excellent terminals like alacritty, kitty and terminator exist and aren't written in javascript
Readit Newsfrau_wacholder commented on The Front-End Developer's Guide to the Terminal joshwcomeau.com/javascrip... · Posted by u/creativedg
frau_wacholder commented on SwitchCenter: an OSX Mission Control alternative (invite-only) · Posted by u/offbeatport
signed up for news. very interested in this, i rely very heavily on window management tools
Thanks for taking the time to write this out. I’ve always been into shortcuts/efficiency when using computers, but vim has made me realize how just how deep the rabbit hole goes and I find it intimidating. With that said, since learning more about vim and why people like it, I find myself getting more and more frustrated every time I instinctively reach for the mouse in vs code or really anything, which while it’s not even that slow, this mental tax leads to an unpleasant development experience. I’m now finding myself at the awkward intersection of seeing how much I leave on the table with vscode in the long term, but also not being anywhere near as productive after making the full switch to vim.
I could care less about what people think of the editor I use. The ergonomic benefit is nice, but after seeing a video[0] of someone who is clearly years ahead in vim fluency, I am so drawn to the idea of having my productivity limited by my thoughts vs how quick I can interaction with my editor.
i think anytime you have to switch a tool, there's going to be a huge dent in productivity. you and i seem to have similar feelings about the mouse and the mental tax that can taint a development experience. what i will say is outside of the productivity dent, there isn't really anything that vscode can do that vim can't. embedded terminals, LSPs, 'command palettes', hell, even githubs Copilot can be achieved in vim.
in my experience the best way to can the fluency you are seeking is to delete vscode, or put it somewhere that you can't see on your machine. when you have a thing that ''''works'''' and you are trying to learn a new thing, it can be an anti-pattern to have such easy access to the thing you are trying to stop using. for example, when i switched to dvorak, i was most successful when i forced myself to only use dvorak, no qwerty, no exceptions. it slowed me down for a week or two, but necessity got me to where i needed to go. the same holds true for vim, that was the same approach i took. even if it means i'm slower for a little bit while i figure out motions, configurations, etc, it got me to where i am now, which is a place where i can do my job in vim (or in my case, evil(vim) mode in emacs) much faster than i could in any editor.
best of luck!
what are your goals?
'if it ain't broke, don't fix it' - if you find that you are able to work comfortably with vscode with the vim extension, and it is meeting all your needs, then honestly that might be what works best for you. However, if you find that you are hitting walls with extensibility or flexibility, _then_ it's time to maybe consider a switch. in my experience of using vim for like a decade now, a successful vim user is often someone who is _obsessed_ with squeezing usability and optimization out of their tools/toolchain. I have seen many an engineer try and force Vim on themselves because of the perception they think others will have of them as a somehow more skilled or 'in the know' engineer. And while i'm not suggesting thats what you are doing, it's definitely a pattern i've seen more and more.
Moral of the story, figure out what you need out of your tools and adapt your toolchain to those needs. and if navigation is your main issue, you should look into easy-motion and Tags, those will help a lot.
And for what it's worth. After a lot of tinkering and thinking about my own goals, i ultimately settled on Doom Emacs, and that's been my preferred editor for a few years now. Many vimmers have found that to be the ideal 'endgame', anecdotally, at least.