For what it's worth: I really don't care to tell people what editor to use. But I do think that everyone should think about spending some time with vimtutor. Not because it will turn you into a 10x developer, or because vim has the best keybindings ever, or anything like that. I've never bought it. But I do believe that it is very likely to make your life easier, even if you don't actually use vim.
Let me explain: I've been an emacs person for decades now. I was never super committed to it, though. In practice, I'll use whatever editor has the best plugin for the language I'm working in. Which means that, for the longest time, I had to try and keep track of 4 or 5 different sets of editor keyboard commands. Which is too damn much for one brain, so I found that, over time, I stopped being as efficient in any editor as I was in emacs 25 years ago.
So why vim? Because every editor worth its salt has an option to use vim keybindings. So you don't have to learn 4, 5, 6 different sets of editor commands. You can learn one, and learn it well.
> Because every editor worth its salt has an option to use vim keybindings.
Including the Unix shell line editor, which typically supports both vi and emacs key bindings, and nothing else. Yet for some reason the default always seems to be emacs rather than vi, even on BSD (e.g. OpenBSD), and even though POSIX only mandates vi mode because "[t]he author of emacs requested that the POSIX emacs mode either be deleted or have a significant number of unspecified conditions."[1] Emacs line editing mode is more confusing for me as I use Joe (WordStar clone) which has emacs-like key combinations but with slightly different assignments. And because of this default I've never made a habit of using line editing commands; there's no way I can unlearn my Joe muscle memory, and over the years I've gotten into the habit of avoiding shell personalizations, to my detriment in this case.
> Because every editor worth its salt has an option to use vim keybindings.
I'm not sure about this. For instance, I'm typing this message in a text box in my browser and I don't have access to vim keybindings. There are many cases where this happens (other example: google docs).
I do use vim whenever I can, but I'd say the most useful keybindings that one can learn are the ones from the OS.
Both Chrome and FF have plugins to add vim key bindings - at least for navigating around the UI and the page. Which would support the argument to learn them. I guess your argument would be stronger if there were other $editor_of_choice key bindings for browser textboxes?
I read this comment 20 minutes ago and tweeted about it. I came back here to provide a link to a browser plugin for vi keybindings and found many other people had also commented with examples- only different ones.
> I'm not sure about this. For instance, I'm typing this message in a text box in my browser and I don't have access to vim keybindings. There are many cases where this happens (other example: google docs).
But both in this box and in google docs (and so many more places) you have access to the basic emacs C-* cursor movement and line manipulation bindings.
One should really know both vi and emacs style basic movement bindings. Both work in many places, sometimes it's one or the other.
GhostText extension for chrome/FF and listed $plugin for $editor means you can live edit a browser textarea in $editor with text sent in real time to browser.
Unfortunately, Google Suite(docs etc.) does not play nice and does not work.
For me, writing short prose like emails or internet comments doesn't really require vim keybindings. It mostly requires keyboard for what it was designed for - inserting text.
Editing source code, on the other hand, benefits much more from vim, because inserting text is only part of it.
I actually learned "vim" on Qt Creator's Vim mode and although I do most of my development now in "real vim" I very much agree with your post. Nearly every editor support vim keybindings which drastically reduces the different shortcuts you have to remember. Even among JetBrains products I find it helps a lot with consistency.
And this means that you can go between systems, not just editors. Before I learned vim bindings, using Linux was so punishing because I was used to using command/ctrl/shift/arrow keys and whatnot to select words, navigate to the beginning and end of the line, etc. After I moved to vim bindings for all my editors, switching to Linux was so easy that it's now where I spend almost all of my time. However, if I do need to use a Mac, I no longer have to fight muscle memory (except for that infernal super key copy/paste).
Agreed yes, and you could use CUA keybindings and be comfortable everywhere, working cross-desktop, cross-terminal, cross-platform. Only a minor variant on the Mac with Cmd instead of Ctrl. Some good options:
- Geany
- Sublime Text
- VS Code
- Notepad++
- micro
- ne
On top of these I usually memorize Ctrl-A and Ctrl-E for the command-line, and "i… :wq" for vim, although haven't needed the latter in a decade.
Sublime Text has a vintage mode which has vim controls, which is very nice. It does not have an advanced set of commands that perhaps other editors might have, but it has the core commands. https://www.sublimetext.com/docs/3/vintage.html
I find that the editors I use most —- TextMate and the JetBrains suite —- also have the option to use Emacs bindings. I try to maintain functional literacy with vi(m), because it tends to be more available by default, but I’ll use Emacs where possible.
A fair point, and, though I'm not personally sad about making the switch, I definitely don't want to imply that other emacs users should drop everything and switch to evil mode.
But, at the risk of branding myself a traitor, I would suggest that anyone who doesn't already have emacs shortcuts burned into their muscle memory should choose to learn the vim ones, because they're somewhat more widely supported.
If you're interested in vim, but hesitant about the lack of IDE bells and whistles, VSCode's vim bindings are so good - with full support for e.g. splits, macros, buffers, ... - that I've finally converted to using that over raw vim.
Most anything that VSCode can do, you can make vim do with plugins, but it is often incredibly time consuming and finnicky to get up and running, whereas with VSCode everything "just works".
All the productivity of being able to edit text in vim, alongside the conveniences of a real, modern IDE.
I'll add that all Jetbrains products (IntelliJ, PyCharm, WebStorm etc) have the IdeaVim plugin which is also great, and it also respects some vimrc configurations too.
I always loved vims movement and editing and hated it's file traversal / project management, so this is a perfect amalgamation
IdeaVim has a few issues due to being thrust onto another application. E.g. Ctrl-V pastes from the clipboard instead of entering visual block mode. Also, it sometimes doesn't process input in order. E.g. pressing Esc Shift-O will sometimes type an "O" before exiting insert mode instead of creating a new line above the cursor. Also useful features that aren't basic movement tend not to work, like text reflowing with gq.
I have a hot key for opening the current file in an actual vim instance whenever I want to write multiline text or use visual block mode.
IdeaVim is faster and less laggy than VSCodeVim in my experience.
You can even use a custom ~/.ideavimrc and bind leader shortcuts to JetBrains actions. I rarely ever touch the mouse in IntelliJ now. It's an ultra-productive environment to have the power of IntelliJ, the convenience of vim, and Spacemacs/Doom Emacs style shortcuts.
It takes a bit of searching and fiddling, but once you hide all the chrome (I even hide tabs at Editor → General → Editor Tabs → Tab Placement = None), install IdeaVim and configure shortcuts how you want them IntelliJ feels just as slick as a tricked-out Emacs/vim, but with better out-of-the-box code intelligence.
On Mac I also remap Ctrl+hjkl system-wide so that I can navigate IntelliJ popovers with vim-ish shortcuts. I use Karabiner for this with the “Vi Mode, left_control + hjkl. shift/option/command + arrow working” option on this page: https://ke-complex-modifications.pqrs.org/?q=%20PC-Style%20S...
I've recently been using VSCode+vim, after about 10 years of using only vim, and another year or so on Spacemacs (emacs + vim mode).
VSCode is awesome, it provides a ton of benefits you don't get from emacs or vanilla vim. I'm really enjoying using it, and there's a chance that it will become my new "main" editor.
That said, the vim mode is not perfect. It only takes a few minutes of work before I run into a limitation of the vim mode, some binding or other that I use and that isn't replicated. More importantly, some things feel broken - there have been cases where undo didn't work properly for me, and cases where numerical arguments to commands messed things up.
That said, I've actually started taking the time to customize the vim mode in VSCode, and it's starting to pay off.
My experience with VSCodeVim is that it's so slow it lags behind my typing. So I went the time consuming and finicky route instead, and it actually works pretty well. I can't think of anything I would get from using VSCode.
Thing is my vim setup is different than vanilla vim, and probably the same for lots of other vim users. Thus, vanilla vim bindings in other editors do not do much for me.
VSCode's vim setup is fairly customizable, and supports features from many popular vim plugins, like vim-surround, easymotion, and many others. I'd encourage you, or anyone else who's curious to give it a shot, because it may be better than you're expecting.
That being said, I haven't been able to make the switch myself yet, even though I sort of want to. The vibe is off.
Agreed 100%, for anybody who has to use a Linux CLI with any regularity.
You don't need to be a vi/vim wizard, but you should at least be able to use it a little bit. Vi is the one editor that's guaranteed to be available basically anywhere.
For working on a complex file (local to my workstation), I almost always prefer Geany or maybe VSCode (depending on the scope of the project). But I'm also semi-decent with vi, and it's saved me a lot of times on embedded systems where I need to log in via serial-console and edit some files.
It's also just faster/easier for editing the odd config-file here or there on a system that I'm logged into. Sure, I could launch a GUI and browse to it (for a local file), or maybe edit with a GUI over SSHFS or something. But if it's a small change? Vim is killer.
Maybe Emacs is better for CLI use, I'm not sure one way or the other. But it's definitely got a much smaller install-base than Vim. And proper-noun Vim has a _much_ smaller install-base than vi-compatible things generally (vim, busybox vi, etc).
Programmers like using vim because it feels like solving a puzzle or RTS micro'ing and/or they have already sunk a huge amount of time into it and aren't willing to walk away (which is fine, but it's not evidence that these tools are better.)
Starting fresh (i.e. no experience with an IDE or vi/emacs) there is zero productivity benefit to choosing vi or emacs over a real IDE in this day and age.
Disclaimer: I am a former vi (~5 years) and emacs (~20 years) fanatic.
Thinking back to my first years as a professional developer, I remember floundering around an IDE trying to find the things I wanted. I ultimately decided that it was worth my time to pick an editor, learn it deeply, and stick with it. That's ultimately where the productivity gain comes from. Lots of people like to talk about how productive vim or emacs or VS code or IDEs are, but I really think it's the fact of knowing your tool really well that leads to the productivity gains.
Vim is great and I love it and have used it for 12 years day in and day out. But I wouldn't say it's what makes me productive, just that I got good at it and know it well.
> Programmers like using vim because it feels like solving a puzzle or RTS micro'ing and/or they have already sunk a huge amount of time into it and aren't willing to walk away (which is fine, but it's not evidence that these tools are better.)
I am (was?) a heavy vim user - 10 years, a .vimrc with thousands of lines and many custom code and settings.
I can vouch that in my case, one of the reasons that I did this is because I enjoyed it. I played around with many editors before I settled on vim, and I enjoyed it immensely. vim was my main editor for many years because it was the best at editing and still is. But for sure I wouldn't have sunk so much time into it without also having fun doing it.
In the last few years, I've started experimenting with other editors/IDEs using vim mode, starting from spacemacs, and now using VSCode.
A bit myopic. Programmers have many different needs and as with almost anything - it depends. "zero productivity benefit" is blatenly false for many people. Now for you, in your current needs, sure. But why attempt to paint the entire developer world your favarite color?
> Starting fresh (i.e. no experience with an IDE or vi/emacs) there is zero productivity benefit to choosing vi or emacs over a real IDE in this day and age.
vi/emacs will definitely still be around in 20 years. Other editors may not be.
IMHO the reasons in 2020 are the same of the last few years and are not changing any time soon: you don't need to leave the terminal AND it is everywhere AND (once you get used to it) it is extremely powerful and blazing fast (most "normal" people think vim users are having some sort of meltdown when they see vim users do even pretty simple stuff).
TBH, although this might be an unpopular opinion among vim users, I don't think vim is worth for coding beyond simple scripting, a decent setup requires way too much work which defeats one of its key points. But for everything else in editing files, nothing compares.
Not quite everywhere. At my current job, I have gotten somewhat proficient with sed, which is the most advanced editor installed on our production systems.
Also, for some reason, many modern systems still only install vi by default. If you know vim, you know vi; but it is missing enough features to be annoying.
A lot of Linux systems (most as far as I know but could be wrong) actually ship vim but in a very stripped down build and set up to run in vi compatibility mode by default, e.g. vim.tiny on Debian and Ubuntu. BSD systems often use nvi, which is quite close to the original vi, and can feel very weird if you are used to vim.
The thing I'm running into recently is that it gets very slow for large files. Unfortunately, where I work, the norm is to have files be thousands and thousands of lines long, which causes my setup which otherwise works fine to become very slow.
It's probably a plugin I'm using, but as you say, it now becomes my responsibility to figure out which one it is. Contrast this with vscode, which works fine out of the box, and already has most features built in.
If you are editing over a network connection and you normally have cursorline on, then try turning it off. That makes a big difference for me when there is network latency.
You're right, the benefits of a great debugger are so overwhelming that putting up with crummy key bindings is worth it. There have been many times where I've been plowing away in some $IDE, then swap over to vim to do some text munging operation in the file like converting some tool output into coded constants, and then swapping back into $IDE to continue the build cycle. It's right there, and it's so good at what it does.
> (most "normal" people think vim users are having some sort of meltdown when they see vim users do even pretty simple stuff).
You know, people always say this, but I've never seen that actually happen. And I've been using vim for around 10 years, with lots of customizations. I consider myself fairly proficient (though by no means an expert).
The reason I learned Vim in 2019 is b/c I wanted a lightweight, powerful, ubiquitous tool. I was willing to overcome the learning curve, but it took time. The most helpful advice I got was from this article https://medium.com/actualize-network/how-to-learn-vim-a-four...:
Week 1: Complete vimtutor once a day, every day
Week 2: Use Vim with minimal config, no plugins
Week 3: Use Vim with minimal plugins
Week 4: Compose Vim commands with verbs and nouns
I'm a vim user turned JetBrains user. I still use IDEAVim inside of all of the JetBrains offerings. I go back and forth wanting to purely use vim but I can't warrant all of the config overhead. To me that's the biggest reason not to use pure vim instead of a vimulator.
The vim ecosystem reminds me of the node ecosystem. It's a choose your own adventure approach. Yes, there are wonderful and powerful tools, but it's always a shotgun of plugins to get a solution for each language you want to support. With JetBrains, I get 90% of the tooling I need for the language I'm using out of the box. The other 10% can be handled by plugins and some small configuration changes.
I'm posting this because I want to be convinced otherwise. Here are the JetBrains features that I can't live without:
- Contexts: https://www.jetbrains.com/help/idea/managing-tasks-and-context.html#work-with-context
- Re > I'm usually working with a 6 to 8 way split. Kind of like the tabs on my browser.
- VCS tooling
- Handles multiple git repos from a top level. I can commit across all repos or a single repo selectively
- File change view
- Merging view
- Per line commit selection
- Inbuilt database tooling
- Ad hoc queries and output directly next to the code you're prototyping
- Database introspection
- Symbol based refactoring
- Visual debugger
- Multiple module repo
- You can configure a language/ecosystem per each directory in your project to get the associated tooling for each directory
- Scratch files
- Local history
- This has saved my ass more than once. It's amazing how far back you can go outside of commit history with this.
I use Visual Studio 99% for my coding, and Visual Studio Code for 1%.
I would prefer to use VIM for editing code or any text because it's a 1000% better than Visual Studio. The problem is, there's 50 other things you do with Visual Studio that is not editing code, and for those things VIM is not that much better, or better at all.
It's not even good at dealing with more than one file. Yeah, I have nerd-tree and have tried explore. meh.
I'll think about it when ReSharper comes up with an add-in for VIM.
Yes, I know Visual Studio Code has VIM mode. . and Visual Studio used to (or maybe still does), but then you're outside the norm of that environment. Ever Visual Studio Code extension is tested with Visual Studio Code. But they're not all tested with Visual Studio Code in VIM mode. That's why I like to stick with defaults and the base-case.
What's needed is for VIM itself to have features beyond just editing text files. It's never going to compete with Visual Studio or Visual Studio code until VIM itself adds those features that make a viable IDE replacement. Today, it ain't.
Here's my suggestion: give neovim nightly a try. With built-in language server support, many new features are easy to add. You can install it like this:
wget https://github.com/neovim/neovim/releases/download/nightly/nvim-linux64.tar.gz -O- | tar zxvf - -C /usr/local --strip=1
And the relevant part of dotfile that adds LSP support and enables a few language servers:
For dealing with multiple files at once, I would recommend using buffers and ideally a fuzzy finder, such as fzf. I would almost advise removing nerdtree while you get used to using buffers, as it probably shouldn't be used for a lot of tasks that it's tempting to use it for.
I also use a buffer explorer plugin and LSP servers too (go to definitions, find references, etc.), but buffers and fzf alone can be very powerful.
Readit News
Let me explain: I've been an emacs person for decades now. I was never super committed to it, though. In practice, I'll use whatever editor has the best plugin for the language I'm working in. Which means that, for the longest time, I had to try and keep track of 4 or 5 different sets of editor keyboard commands. Which is too damn much for one brain, so I found that, over time, I stopped being as efficient in any editor as I was in emacs 25 years ago.
So why vim? Because every editor worth its salt has an option to use vim keybindings. So you don't have to learn 4, 5, 6 different sets of editor commands. You can learn one, and learn it well.
Including the Unix shell line editor, which typically supports both vi and emacs key bindings, and nothing else. Yet for some reason the default always seems to be emacs rather than vi, even on BSD (e.g. OpenBSD), and even though POSIX only mandates vi mode because "[t]he author of emacs requested that the POSIX emacs mode either be deleted or have a significant number of unspecified conditions."[1] Emacs line editing mode is more confusing for me as I use Joe (WordStar clone) which has emacs-like key combinations but with slightly different assignments. And because of this default I've never made a habit of using line editing commands; there's no way I can unlearn my Joe muscle memory, and over the years I've gotten into the habit of avoiding shell personalizations, to my detriment in this case.
[1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/s...
I like my emacs line editing mode :D
I'm not sure about this. For instance, I'm typing this message in a text box in my browser and I don't have access to vim keybindings. There are many cases where this happens (other example: google docs).
I do use vim whenever I can, but I'd say the most useful keybindings that one can learn are the ones from the OS.
Here’s another:
https://github.com/akahuku/wasavi
But both in this box and in google docs (and so many more places) you have access to the basic emacs C-* cursor movement and line manipulation bindings.
One should really know both vi and emacs style basic movement bindings. Both work in many places, sometimes it's one or the other.
> Sometimes, you edit text outside of Vim. These are sad times. Enter vim-anywhere!
https://github.com/cknadler/vim-anywhere
https://github.com/GhostText/GhostText
GhostText extension for chrome/FF and listed $plugin for $editor means you can live edit a browser textarea in $editor with text sent in real time to browser.
Unfortunately, Google Suite(docs etc.) does not play nice and does not work.
Worth checking out.
Also for a more embedded vim experience: https://github.com/glacambre/firenvim
- google chrome
- sql server management studio
- jupyter notebook
- jupyter lab
- visual studio code
- ms visual studio
- dbeaver
- eclipse
- sublime text 2
- hackerank, iirc
Editing source code, on the other hand, benefits much more from vim, because inserting text is only part of it.
Deleted Comment
Firefox: https://www.reddit.com/r/firefox/comments/8y0q23/vim_mode_fo...
- Geany
- Sublime Text
- VS Code
- Notepad++
- micro
- ne
On top of these I usually memorize Ctrl-A and Ctrl-E for the command-line, and "i… :wq" for vim, although haven't needed the latter in a decade.
But, at the risk of branding myself a traitor, I would suggest that anyone who doesn't already have emacs shortcuts burned into their muscle memory should choose to learn the vim ones, because they're somewhat more widely supported.
(And to use doom emacs to do it.)
Also a lot of inputs use Emacs binding or a subset of it: Bash and other shells, Cisco routers, heck, even in Slack you can Crtl-a or Crtl-k.
Yeah, this is weird to me. I've seen some people list it on their resume. Why should I care what editor you use?
Deleted Comment
Most anything that VSCode can do, you can make vim do with plugins, but it is often incredibly time consuming and finnicky to get up and running, whereas with VSCode everything "just works".
All the productivity of being able to edit text in vim, alongside the conveniences of a real, modern IDE.
I always loved vims movement and editing and hated it's file traversal / project management, so this is a perfect amalgamation
I have a hot key for opening the current file in an actual vim instance whenever I want to write multiline text or use visual block mode.
You can even use a custom ~/.ideavimrc and bind leader shortcuts to JetBrains actions. I rarely ever touch the mouse in IntelliJ now. It's an ultra-productive environment to have the power of IntelliJ, the convenience of vim, and Spacemacs/Doom Emacs style shortcuts.
For example, to manage projects:
Or to create/switch git branches: Or to bring up the nav bar to change or create new files (Ctrl/Cmd + N once the nav bar is visible): Or to summon git blame annotations in the current file (repeat to dismiss them): Or manipulate windows: Or summon “Refactor This” at the cursor point: You can get a list of available actions for your current environment and plugins with the :actionlist command.I only started playing with this recently but my current config is here for those interested:
https://gist.github.com/nickcernis/bcb5cb7f55c07ed3de8287d16...
It takes a bit of searching and fiddling, but once you hide all the chrome (I even hide tabs at Editor → General → Editor Tabs → Tab Placement = None), install IdeaVim and configure shortcuts how you want them IntelliJ feels just as slick as a tricked-out Emacs/vim, but with better out-of-the-box code intelligence.
On Mac I also remap Ctrl+hjkl system-wide so that I can navigate IntelliJ popovers with vim-ish shortcuts. I use Karabiner for this with the “Vi Mode, left_control + hjkl. shift/option/command + arrow working” option on this page: https://ke-complex-modifications.pqrs.org/?q=%20PC-Style%20S...
VSCode is awesome, it provides a ton of benefits you don't get from emacs or vanilla vim. I'm really enjoying using it, and there's a chance that it will become my new "main" editor.
That said, the vim mode is not perfect. It only takes a few minutes of work before I run into a limitation of the vim mode, some binding or other that I use and that isn't replicated. More importantly, some things feel broken - there have been cases where undo didn't work properly for me, and cases where numerical arguments to commands messed things up.
That said, I've actually started taking the time to customize the vim mode in VSCode, and it's starting to pay off.
That being said, I haven't been able to make the switch myself yet, even though I sort of want to. The vibe is off.
You don't need to be a vi/vim wizard, but you should at least be able to use it a little bit. Vi is the one editor that's guaranteed to be available basically anywhere.
For working on a complex file (local to my workstation), I almost always prefer Geany or maybe VSCode (depending on the scope of the project). But I'm also semi-decent with vi, and it's saved me a lot of times on embedded systems where I need to log in via serial-console and edit some files.
It's also just faster/easier for editing the odd config-file here or there on a system that I'm logged into. Sure, I could launch a GUI and browse to it (for a local file), or maybe edit with a GUI over SSHFS or something. But if it's a small change? Vim is killer.
Maybe Emacs is better for CLI use, I'm not sure one way or the other. But it's definitely got a much smaller install-base than Vim. And proper-noun Vim has a _much_ smaller install-base than vi-compatible things generally (vim, busybox vi, etc).
Programmers like using vim because it feels like solving a puzzle or RTS micro'ing and/or they have already sunk a huge amount of time into it and aren't willing to walk away (which is fine, but it's not evidence that these tools are better.)
Starting fresh (i.e. no experience with an IDE or vi/emacs) there is zero productivity benefit to choosing vi or emacs over a real IDE in this day and age.
Disclaimer: I am a former vi (~5 years) and emacs (~20 years) fanatic.
Vim is great and I love it and have used it for 12 years day in and day out. But I wouldn't say it's what makes me productive, just that I got good at it and know it well.
I am (was?) a heavy vim user - 10 years, a .vimrc with thousands of lines and many custom code and settings.
I can vouch that in my case, one of the reasons that I did this is because I enjoyed it. I played around with many editors before I settled on vim, and I enjoyed it immensely. vim was my main editor for many years because it was the best at editing and still is. But for sure I wouldn't have sunk so much time into it without also having fun doing it.
In the last few years, I've started experimenting with other editors/IDEs using vim mode, starting from spacemacs, and now using VSCode.
Dead Comment
vi/emacs will definitely still be around in 20 years. Other editors may not be.
TBH, although this might be an unpopular opinion among vim users, I don't think vim is worth for coding beyond simple scripting, a decent setup requires way too much work which defeats one of its key points. But for everything else in editing files, nothing compares.
Also, for some reason, many modern systems still only install vi by default. If you know vim, you know vi; but it is missing enough features to be annoying.
The thing I'm running into recently is that it gets very slow for large files. Unfortunately, where I work, the norm is to have files be thousands and thousands of lines long, which causes my setup which otherwise works fine to become very slow.
It's probably a plugin I'm using, but as you say, it now becomes my responsibility to figure out which one it is. Contrast this with vscode, which works fine out of the box, and already has most features built in.
You know, people always say this, but I've never seen that actually happen. And I've been using vim for around 10 years, with lots of customizations. I consider myself fairly proficient (though by no means an expert).
Week 1: Complete vimtutor once a day, every day Week 2: Use Vim with minimal config, no plugins Week 3: Use Vim with minimal plugins Week 4: Compose Vim commands with verbs and nouns
The vim ecosystem reminds me of the node ecosystem. It's a choose your own adventure approach. Yes, there are wonderful and powerful tools, but it's always a shotgun of plugins to get a solution for each language you want to support. With JetBrains, I get 90% of the tooling I need for the language I'm using out of the box. The other 10% can be handled by plugins and some small configuration changes.
I'm posting this because I want to be convinced otherwise. Here are the JetBrains features that I can't live without:
It's not even good at dealing with more than one file. Yeah, I have nerd-tree and have tried explore. meh.
I'll think about it when ReSharper comes up with an add-in for VIM.
Yes, I know Visual Studio Code has VIM mode. . and Visual Studio used to (or maybe still does), but then you're outside the norm of that environment. Ever Visual Studio Code extension is tested with Visual Studio Code. But they're not all tested with Visual Studio Code in VIM mode. That's why I like to stick with defaults and the base-case.
What's needed is for VIM itself to have features beyond just editing text files. It's never going to compete with Visual Studio or Visual Studio code until VIM itself adds those features that make a viable IDE replacement. Today, it ain't.
https://github.com/d33tah/dotfiles/blob/master/dotfiles/vimr...
You'll also need to run:
Personally I was surprised many times how easy it was to add decent support for new languages. It really is a godsend.I also use a buffer explorer plugin and LSP servers too (go to definitions, find references, etc.), but buffers and fzf alone can be very powerful.