21–30 of 42 posts
The biggest advantage of vim, besides the language for editing text in normal mode, is that you are really fast and it just feels like you never have to wait for your computer anymore.
That said when I do configure, I'm dedicated to it. The goal is to set it and forget it for literally years in order to build up muscle memory. So it's worth playing around and finding what works.
It did take me a few months of consistent use to get better in Vim than other editors. I think that's faster than most people? I'm a pretty good typist so I think that probably makes a big difference. All of which is to say:
- Definitely stick with it (maybe try to think of it as "cool" rather than a slog, maybe investigate cool plugins or color schemes to help reinforce that)
- Invest in your config
- Work on your typing (and address any discomfort that arises--super important)
Stick with VSCode. “Editing code on the server”? This isn’t 2010. We use docker and continuous deployment, and if someone is trying to edit production code in the server something is deeply wrong.
But maybe they are doing something super high performance and need fast edit test cycles they can't get on their laptop, although I'm not exactly sure what kind of task needs that.
If you like VSCode and feel productive in it, you should stick with it. If you're in a situation where you're able to go slower and ramp up with vim, I think that would be a good time to try it out. The end-game is that your vim-config is truly portable, and no matter where you go, you'll be able to easily duplicate your work environment. Also, once you master the motions, you'll be much faster navigating bigger code-bases and can easily work on a server if need be.
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 success…
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 no…
As for mouse-reaching, just flip it over (maybe put a sticky note over laptop trackpads). If you touch it, think, hey, there's probably a way to do this without the mouse. For vim usage, I would also say the same thing about arrow keys (especially in insert mode). Disable these training wheels & see your productivity skyrocket.
If it's not fun, then it's probably not worth it. It really depends on what VIM can do to improve your current workflow. So, you may need to drop the VSCode mindset while you start using VIM.
> but now that I’m trying to navigate medium/large projects,
I actually have trouble navigating large projects in VSCode. The buffer, tab, window model that Vim uses makes more sense to me (but it's unique to VIM afaik, so it may be jarring at first). Combine that with a fuzzy finder[1] and it allows:
- rip-grep to search for files with text / file names
- Searching through currently currently opened buffers
Whenever I have to use VSCode (mainly for the live share feature, I find myself pretty lost with VSCode's tab based interface (I usually end up with like 20 tabs cluttering my workspace, and tabs are local to a split, which is jarring for me).
> the vim endgame looks like
It never _really_ ends. Some VIM features that I miss when I use another editor are:
- Really nice integration with terminal commands. One thing that I do very often is copy the name of the current file: `!echo % | xclip -sel clip` so I can use the filename as an argument in a terminal split (running tests for example)
- Filters (`:help !`) so I can pass parts of a file in to a program that accepts standard input. Example: `'!jq` to prettify bits of JSON.
- Global commands and macros. VSCode vim supports them, but I've noticed that they can run pretty slowly.
- The buffer, tab, window, model (probably the biggest one I miss when I start using VSCode)
For LSP support, I've tried to migrate to neovim's native LSP tools, but I still find COC to be a lot more intuitive. You should feel right at home with it since a lot of the plugins are similar to their VSCode counterpart.
If you'd like a really general and guided tour of VIM, I'd recommend picking up Practial Vim[2] It really helped me understand the workflow a bit more. Approaching VIM with the mindset of another editor wont give you all the benefits of using VIM. Though, if the workflow doesn't click, then that's not a big deal. You can always go back to VSCode.
[1] https://github.com/Shougo/denite.nvim (many people use Telescope: https://github.com/nvim-telescope/telescope.nvim) [2] https://www.amazon.com/Practical-Vim-Thought-Pragmatic-Progr...
4-5 years ago I was all about the editors with pretty UIs (VS Code, Brackets, Atom, JetBrains IDEs, etc). I thought Vim was dumb and outdated. Boy was I wrong. I eventually decided to try out Emacs, and settled on Spacemacs, which comes with Evil mode pre-installed (a Vim emulation layer on top of Emacs), so I basically had to learn some Vim bindings. Now I'm on Doom, which uses them even more heavily. And boy do I r…
> jumping through UIs and pointing and clicking. That's strange, most code editors have advanced keyboard shortcuts for almost everything you can do with pointing and clicking. You just have to learn the combos.
1. While you are working with software tools, keep an eye out for actions you repeat and/or spend quite a bit of time on.
2. Find out if there is a command (or macro facility etc.) that will do this action quicker. Read the documentation, ask a friend, or look at how others do this.
3. Train using the command. Do this until your fingers type it without thinking.
This means that you can learn new commands only as the need comes up by observing what you do. Which commands you will want to learn thus depend on the operations you are frequently doing and/or that cost you a lot of time.
As I said, that strategy is applicable in general. Tools however differ in how well they support it, e.g. in terms of available commands and facilities.
You could start applying that strategy in VSCode (which I’m not familiar with, by the way). If it works well enough, great. If you find it limiting, switch to Vim, Emacs, or some other IDE that serves your needs better.