Vim is still one of the best IDEs out there, and I do mean IDE. I have git, gdb, terminal, and LSP integration. I've got spell check. I've got tags, cscope, snippets, and lint warnings. I've got documentation and hover support. On top of that, my editor uses megabytes instead of gigabytes of RAM, and I can run it from any terminal, on any computer. I can run it on my iPad Pro using blink. I can run it over mosh or ssh. I've been able to use it at every job I've ever worked at even as workplaces have switched from Sublime to Atom to VS Code. It doesn't cost me a dime to use it. I've been writing C, Go, Rust while working on bootloaders, kernel patches, and firmware for years and years and Vim has been a powerful tool to keep me as productive as possible. Even after trying CLion, VSCode, Atom, etc. I always come back to Vim realizing that these sluggish GUI Java/Javascript apps simply don't offer enough to compare to the decades of work that has gone into Vim.
Vim and Emacs are an investment, but the investment pays off ten fold. On top of their powerful features you get to support free and open source software that isn't being steered by corporations that want to keep you locked in and collect as much analytical data on your habits as possible. They aren't looking to lock you into an editor as a service. We've seen with neovim that the system works and has made both vim and neovim even better through healthy competition. Free and open source for the tools you use everyday is the way to go.
>I have git, gdb, terminal, and LSP integration. I've got spell check. I've got tags, cscope, snippets, and lint warnings.
Apart from the built-in features (like :terminal), somehow I haven't yet explored plugins to enhance my Vim usage. Granted that coding projects over 100 lines are rare for me, I still feel like I should try them out and see if I can get used to them. If not pure coding projects, at least for things like markdown, having a preview could help.
Personally, I suggest taking a look at a few "classic" plugins. For starters, anything by Tim Pope.
Avoid the massive omnibus plugin packages. I find they often try to turn Vim into something it's not.
Nothing against people who use and enjoy those -- I'm not advocating for elitism or purism. I just feel like if you really want Vim to look and feel like (e.g.) VSCode, you're better off using VSCode.
Instead, I've gotten the most out of the plugins that I've taken the time to hand-pick and configure myself. Largely because I took that time to understand them.
From what I know about Vim this isn't unusual. There is a division between those who treat Vim as a constant tool that should be kept as close to the defaults as possible, so that you can work anywhere it is installed (I'd consider this the classical approach inspired by vi), others who value extending and modifying it to match their needs and preferences (this seems to me to lean towards Emacs' spirit). As Vim is both a vi-clone but also has the abilities to be extended, I don't think either is more wrong than the other. My sympathies go towards the former, because Emacs is my Emacs.
I write C++ and Python for $DAYJOB and I use Emacs with no extra configuration (plugins, evil mode, etc). Out of the box it takes a while to understand its flow (the emacs tutor is excellent), but it's quite usable and nice.
Emacs has TAGS-based completion (basically completing known symbols in a project) and you can use M-x compile to navigate the output of a command that generates warnings and error messages. It is not the same workflow as other popular editors, but has it's advantages too.
I don't think that's what they meant. I think they meant "I use Vim for lightweight, default editing. When I want to extend my editor precisely to my liking, (like in Emacs), I use Emacs."
Ah, I know RMS claims to not using any plugins and barely any customizations since emacs is "exactly how he wants it" as the author. I am curious if there are others who feel the same way.
In the era of neovim, you can get very far with very few plugins.
Put together neovim, nvim-treesitter and nvim-lspconfig (which are both "official" plugins), and fzf.vim, and you end up with a decent IDE with only one non-official plugin.
Less plugins = less to go wrong, easier to reason about, less configuration needed, more zen.
> If not pure coding projects, at least for things like markdown, having a preview could help.
Everybody's needs are different, of course, but I personally find that Vimwiki [1] gives me all the preview I need, right in the editor, when editing Markdown.
I've been using Vim for more than 10 years, and I had no idea about :terminal. I was using tmux instead to get terminals side-by-side but using panes looks super useful too. Thanks! :)
This is what I love about Vim. It's by far my favorite editor even with just basic usage, and I consistently learn new tricks that make it somehow even better.
Sorry, but I'm not so sure with VSCode I'm nearly instantly productive, with vim I have to spend a lot of time before being able to navigate in C++ files..
C/C++ have been around for a long time and have great support in Vim. You can build a cscope database (cscope -b -q -k) and then use :cs find -
- a: Find assignments to this symbol
- c: Find functions calling this function
- d: Find functions called by this function
- e: Find this egrep pattern
- f: Find this file
- i: Find files #including this file
- s: Find this C symbol
- t: Find this text string
And if you want more you just need a single plugin w0rp/ale and have clangd installed, no configuration needed to get the same LSP support you can get with VSCode.
Cscope supports C, C++, and Java. It should work the same for all three. You need to build your cscope database, and for Java this will require getting a list of files using find, and then use :cs in vim to load it. I primarily write C and I put the build commands in my Makefiles for ctags and cscope. The Linux kernel also has this feature as well. If you go into the kernel source you can just run `make tags` and `make cscope` and it lets you browse the 100s of millions of lines of kernel source with either.
What I like about vim (and other terminal editors alike) the most is the predictability. For any decent tools, you will get used to them over time, things become muscle memories; and that’s good. You learn it once, and you can benefit from it for a looong time. You know how the tool works, you know how to use it, and it won’t change by itself. Remember that feeling when your favorite desktop app, website release a new upgrade and it just stop making sense to you? Or it’s unclear how things work anymore? That’s what I am talking about.
A related point is that you can confidently invest in vim knowing that it will be around for a good deal longer. I often find it pointless getting too invested with a shiny bit of proprietary software because I don't know how long I'll be using it for.
It seems worth noting that this is mostly a culture difference.
Many terminal users will be upset if you change a tool out from under them. Many desktop users don't know how to vocalize it.
In addition, it's more common afaict for cli/tui tools to be open source, so if someone does change a tool out from under you it's possible to fork the old version and keep the UI you like.
Here are some of the things I use to increase the range of programs for which I can use vi keybindings:
* vscodevim extension for Vscode
* "set -o vi" in Bash
* Vim Vixen plugin for Firefox
* you can use ctrl-alt-j in gdb. And that might (should?) work in other programs which use GNU Readline to get vi keybindings. The only thing I miss with the vi bindings in bash/readline is "ge/gE" from vim (move backwards to the end of the word).
I was always a heavy vim user, and I’ve had a good time switching to doom emacs: it seems easier to do more stuff outside of code editing in emacs, and I’ve got full vim keybindings in pretty much anything I can get emacs to do. I even have a browser plug-in that opens an emacs editing session for any text input on a page!
I stumbled across your vids a few months ago after I decided to checkout neovim & try for the full "vim as an IDE" experience. They are defiantly some of the most helpful videos I came across, great work!
I use vim as my IDE daily, and swear by it. I was just thinking of things that I still 'shell out' for because it feels more convenient and wanted to get other people's opinion on how they solve it.
1) Open a file (in a split) in the same git repo that shows up under 'git status'. I'm way too comfortable hitting ctrl-z, git s, grab mouse, copy, fg, :sp ctrl<v>. Is there a simple pattern/plugin to just list modified files and open one in a split?
2) Open a file in another repo. So I'm in src/foo, and I need to open a file (in a split) in src/bar. I often use NerdTree for this but it feels slow and cumbersome, but maybe I'm using nerdtree wrong? Something like being able to just type <leader><key> <start typing a path and get fzf-style results> or something like that.
3) Find where a function/method is defined in the current git repo. Right now my pattern is I have Ack search (but using fzf) bound to backslash, so I type like \'def funcname' but this feels so cumbersome. Is there a faster way to just say "open the file where the function name my cursor is in is defined"?
For reference, in the shell I tend to rely heavily on fzf and fzf-using functions (e.g. 'vis' will let me select from changed files via fzf and open it in vim, 'vif' will let me select from any filename under the current dir in vim) and I guess I'm mostly looking for bringing that power and flexibility into vim without shelling out or lots of arrow-arrow-return-arrow-arrow-return in nerdtree.
> Called with no arguments, `:Git` opens a summary window with dirty files and unpushed and unpulled commits. Press `g?` to bring up a list of maps for numerous operations including diffing, staging, committing, rebasing, and stashing. (This is the successor to the old `:Gstatus`.) [1]
To open file in split: <C-w>f
2) fugitive works with it too. See this thread [2]
3) I use fzf [3] too. My pattern is a bit shorter: '\r' (mnemonic from '' for search the word under cursor). With the mapping and command:
```
nnoremap <silent> <Leader>r* :Rgw <C-R><C-W><CR> "" <C-R><C-W> - to paste word under cursor in command prompt
1) I just use fugitive[0] for that. `git status` in vim is now just the `:G`, command, though I map it to `gs` so it's even quicker.
2) I can't really help you there, at least not in vanilla vim. I make heavy use of tmux and never work on my more than one repo in the same vim instance, nor is my vim's current working directory every anything other than the root of the repo I'm in. So if I do need to open a file in another repo and want to see two repos side-by-side (which is rare but it happens), I make a tmux split.
3) gutentags [1] can help with this. Though nothing is better than using a language server for your given language. That said, I still just have gutentags and mostly just grep/search for `def func` like you currently do.
1. Fugitive.vim
2. Fzf.vim . If you launch vim from a path includes both repos, it will just work. If not, you can provide a starting path argument to the fzf file picker.
3. ctags (universal-ctags) + native vim tag jump functionality. Pair with gutentags plug-in to auto generate ctags when files change and the such.
For 2) you might want to look into :lcd. This changes the directory of the current window (there are other commands to cd for different contexts). So what I do is ctrl-w v to split, followed by :lcd /some/path and then, in that window, I can use my fuzzy finder (or :grep).
It's still quite a few commands but the advantage is that you get a buffer where all your commands should operate on $other_repo.
For (2), I have the following in my .vimrc and it does close to what you've described:
nnoremap <C-p> :FZF ~/src<CR>
I feel like there you could make it open the result in a split either by modifying this mapping command, or by hitting something other than enter once you have your target selected in the fzf window.
I just open the split first, then C-p in the split.
I spent about 4 months on it daily unable to get up to speed how I was originally.
This may just speak to my own inabilities of muscle memory, and granted, If I used Vim a little younger, I think the outcome would be different.
But the thing is, I'm productive enough.
Furthermore, I found the mouse to be faster in many cases - I only believe the top 10% of vim users who have spent countless hours tailoring their config to be the most "productive" in terms of typing.
I say productive in terms of typing, because when we code, a grand majority of our productivity actually comes from our brain.
Squeezing out additional wpm actually has very little relevance to productivity.
But looking at seasoned Vim users looks cool though, and it definitely does give those style points.
I've used Vim for many years and I don't recommend people learn it. The things which make Vim strong (cross-platform, plugin ecosystem) has been subsumed by VSC for the most part, and what is left is Vim's unique philosophy of text editing, which by itself is an incredibly modest proposition.
Software like VS Code lives in cycles. It's popular now but you will see it being less popular every year. People will notice how it grows slower, buggier, and probably some unpopular decisions by Microsoft will annoy users. This is the default path for big software.
Vim will always be there and because it's not backed by big tech, it will continue to be modular, fast and modern.
Much like Linux, learning it means you are free, powerful and you will not get affected by the whims of big tech. This is very valuable.
Every year you use free software, you invest time in skills that won't go away and will support you for life.
Yup, that's also why I decided to get good in vim.
I was pretty happy in TextMate at the time, but the popularity tide had turned as he was working on TextMate2. The writing appeared to be on the wall, so I learnt vim properly. Sublime took over, then came Atom, now VSCode. Neovim is home for me now, and that's been a whole other beast to configure, but vim has just been such a stable, efficient environment for me for almost 15 years now.
If you actually want to take full advantage of the editor and its plugins, then the answer is yes. It's easier to immediately get to grips with vscode than vim, but once you've understood the basics for vim (which takes maybe a full day of studying, and then some practice over a few months), the two editors are pretty equivalent in how much time you have to spend on super-powering them.
I think that's relevant because once you've seen how vim (or emacs) can be customised, it's kinda hard to accept vscode as is, without spending significant time customising it. To me, that makes your argument that it's easy to move to the next big thing, mostly invalid... it would be easy if I don't care about learning and customising the tool.
Of course mileage may vary depending on how picky you are with your setup. I'll admit I lie on the picky end of the spectrum.
> the two editors are pretty equivalent in how much time you have to spend on super-powering them.
One of the most disagreeable things I have ever disagreed with.
If you remove your bias, you'd find it within yourself that you would disagree with your own statement as well.
When the next VSCode comes along, I will move onto it with ease. Please do not ever consider that I'd get onboarded to vim just as quickly - I've spent enough time with vim to know such.
> If you remove your bias, you'd find it within yourself that you would disagree with your own statement as well.
You don't know me, or what my experiences are. So please don't assume that I'm biased, simply because I have a different view than you. Likewise, please don't assume that I would share your view if I just understood things as well as you do.
I maintain a small amount of config files for vscode, a medium amount for vim, and a large amount for emacs+evil. I use all three editors for work, and have done so for years. The thing holding me back from switching to vscode fully is precisely the fact that it would take too much effort to customise it as well as I have customised vim and emacs.
Obviously your experience doesn't agree with mine, and I clearly can't say why. All I can say is that vim simply "clicked" for me when I first learnt it. I have coached enough coworkers that I can say the same thing applies to most people who take the time to learn the "vim way". And of course vim would not be as popular as it is, if that wasn't generally the case.
Perhaps vim simply doesn't speak to you. That's okay, nothing wrong with that.
But it's objectively complete nonsense to claim that vscode does not require a substantial time-investment if you really want to super-power it. And that has nothing to do with the editor, it has everything to do with the fact that the editing experience is highly individual. If you really think you will move onto the next vscode with ease, all that tells me is that you won't take the time to learn the tool.
>Obviously your experience doesn't agree with mine, and I clearly can't say why. All I can say is that vim simply "clicked" for me when I first learnt it. I have coached enough coworkers that I can say the same thing applies to most people who take the time to learn the "vim way". And of course vim would not be as popular as it is, if that wasn't generally the case.
From my very first comment about the matter.
>>I spent about 4 months on it daily unable to get up to speed how I was originally.
>>This may just speak to my own inabilities of muscle memory, and granted, If I used Vim a little younger, I think the outcome would be different.
You keep talking about configuration, when the bigger elephant in the room is learning the keybindings.
It took me almost 2 months to be comfortable without looking at the vim cheatsheet
It then took another 2 months to get to a speed at which I felt like I could be productive.
And at that point, my typescript projects were so incredibly slow, I had to quit vim.
>But it's objectively complete nonsense to claim that vscode does not require a substantial time-investment if you really want to super-power it.
I still disagree as GUIs makes configurations a lot simpler, and as plugins are just a click away.
Again, if you include learning the keybindings, which for some reason you refuse to, you'd find it within yourself that you would disagree with your initial statement.
> Again, if you include learning the keybindings, which for some reason you refuse to, you'd find it within yourself that you would disagree with your initial statement.
This is such a presumptuous and arrogant statement to make.
Not only do I include learning the key-bindings, I also am thinking of customising your own key-bindings. But simply learning the default key-bindings should not take you 2 months. Even if it doesn't click for you, I am convinced you could learn this faster.
And besides, vscode also has a ton of key-bindings. That's one of the very reasons why I haven't gone full in on vscode. Your 2 months to learn vim key-bindings should also take 2 months in vscode, if you approach it with the same efficiency. The way you respond here, I'm starting to think you'd already made up your mind to dislike vim before you tried it.
> I still disagree as GUIs makes configurations a lot simpler, and as plugins are just a click away.
And each plugin also comes with key-bindings and customisability. If you simply install a plugin and leave it at that, then you haven't spent the time actually learning it. Installing a plugin in vim is as simple as adding a single line in vimrc.
1. You don't need to learn macros for VSCode. I personally use just about a dozen of them, but the mouse suffices for majority of the usecases. I don't have the necessity to shave off milliseconds.
2. Vim requires 2-3 dozens of keybindings memorized in order to have a decent feel for the editor, which of 1-2 hours of daily practice took me about 2 months.
3. The productivity gained from keybindings/macros/file navigation is negligible in the bigger scheme of things as it is your brain that does the heavy lifting in code.
I don't understand why you are so obsessed with the idea that me disagreeing with you means I haven't seen the light. It's a little weird, to be honest. There should be room for having different experiences, without that necessarily meaning the other person is wrong.
> apparently it isn't just "one line in vimrc"
That documentation includes info on how to customise the setup. As you should do, if you want to take full advantage of the plugin. Bottomline: this documentation is not equivalent to a single click in vscode. It's still a single line if you merely want to install the plugin.
> The problem with keybindings on vscode is that it isn't necessary to learn them
It's necessary if you want to be a power user. Your original argument was that anyone should be able to jump onto the next vscode with minimal effort. But this is clearly not the case if you want to be a power user. If you don't want to, that's fine. But your size doesn't fit all.
I spent awhile learning vim, I use it often. But I don’t use any of the fancy stuff I see people doing I just do basic configuration editing and what not
I'm not a VIM expert, but I do use it as my primary editor. Visual Studio Code is my secondary editor and I flip between them, but tend to be in vim most often.
I don't think that the utility of VIM comes from squeezing out wpm, but in it's navigational and editing capabilities. Particularly when paired with a relevant language server, code navigation is a breeze. Additionally, being able to run it on a remote server, in a tmux session, means I can drop off and pick up my work from basically any machine without any effort.
My vim config is pretty barebones, its primarily just language server support and git fugitive.
Now, modern vscode setup with a remote plugin, language plugin (and vim keybinding plugin) gets you basically the same benefits. For me personally though, I find a few things more clunky in that setup than the vim version of it, mostly around code navigation.
bought and used many IDEs (still owns all jetbrains stuff) but 99% of the time I'm using vim for everything.
it does have a learning curve and took a while to settle down all those key bindings with plugins. once you past that point, it never stands in the way, and I don't need move my fingers away from the keyboard to pick the mouse and click here and there then move my hands back to keyboard anymore.
Is Vim with plugin still as good when you have to switch between multiple languages with good debugging support? or some languages/plugins are better supported than other?
I mostly use copilot and the most popular LSP for any language I'm developing. And I mostly write Go and Python. Any mature, popular language will have plenty of tooling and plugins for you to work with, but not all tooling is created equal. For me, everything works much better in Go than in Python. Copilot suggestions are far more useful, the LSP has a lot more useful info to give me, etc.
There are a couple "flavors" of neovim that do a lot of the heavy lifting for you as far as plugin setup to give you a better initial setup experience, otherwise you will need to put in some work to finding all the plugins you want, and some of that work will need to be repeated for each language you want to write.
I still use vim quite a bit, especially because I live in the terminal, but the last few years I’ve been converted to VSCode for my IDE. I still live in the terminal just within VSCode.
This is great. Just a simple 100 page document on how to use a editor/IDE. No wonder I have been using it for 20 years.
I tried shifting to VScode but was frustrated deleting the :wq! keys all the time, so I had to jump back to VIM.
Product teams a learn a thing or two from VIM on how to make your product sticky.
What made Vim click for me, and it's sort of a cliché, is Vimtutor. I went through the entire `vimtutor` on the command line, and all of a sudden the "dogma" behind Vim clicked. Vim keystrokes have been my default for so long that I find myself pressing Caps Lock or Escape basically everywhere.
I really can't operate without caps lock as escape. That is one of the reason I am apprehensive about setting a leader key(space) because getting used to that will make me incompatible with everyone else's machine.
I've never really understood everyone's hate for using backslash for the leader key. It's easily reachable with my pinky finger without much hand contortion.
I agree with your point though; part of the reason I'm always apprehensive about redefining keys is because I'm never 100% sure whose keyboard I'm going to be typing on (though that's less of an issue now cuz of COVID).
When I was first learning (and consequently perving on everyone else’s vimrcs), I noticed a meme where many people use comma for leader. I followed suit but later learned from Practical Vim that this is a bad idea because comma already has an important function.
(Discovering what that function is and why it’s important is left as an exercise for the reader).
I just can't find a way to get myself to the point where I feel like I prefer vim over VS Code.
For making changes in a single small file, vim is good enough and I enjoy using it. But any time I find myself dealing with bigger changes and multiple or big files (Stuff that is more "Project" scope rather than "Code" scope, if that makes sense) I always feel like I want to be using VS Code instead.
vim will ~never have a better debugging experience than VS Code (or any proper IDE) I think; and That's OK. Each tool has it's own uses. I'm a Vim fanboy; but i still do any non-trivial (local) change in Vim. If i have to dev on a build server; local(tmux) Vim vs remote-ssh VSCode it becomes closer.
Vim movement is amazing. However, I've never seen any great benefits to learning more advanced features of the application, it's just too much to think about.
I was in the same boat then I switched to Doom Emacs it has all the VIM keybindings but a lot of the emacs power and it covered a lot of the places that VIM was lacking before I now find it one of the best prodcutivity decisions I've made in a long time.
Plus once you figure out org mode and magit you can't imagine living life without them.
(Also as a humrous aside I just tried finishing this post by typing :wq! because of force of habit, I love vim)
> I've never seen any great benefits to learning more advanced features of the application, it's just too much to think about.
Once you learn them, there is nothing to think about; that's the beauty. It's muscle memory - I swear (I haven't tested with an EKG) that the signal doesn't enter my conciousness, like an old violinist playing.
I use vim a ton, but I guess never the complex movements as much, because if I want to do anything ever so slightly complex, I've got to sit there and think about it more than I really should... There is just too much for it all to end up as muscle memory, there's no way everything gets used enough for that to happen.
> There is just too much for it all to end up as muscle memory, there's no way everything gets used enough for that to happen.
Yes, that only applies to things I use regularly, though they can be easily combined into larger commands. I'm not at all suggesting that things I use once a year go to muscle memory, much less all of Vim (probably only Moolenaar knows it all)!
It depends on how much you use it. Being able to open multiple files, visually diff from a VCS, and find/replace in all open buffers is quite handy if you're in the CLI quite a lot
Vim is very big, so don't learn it until you need it. For example, if you want to draw diagrams in Vim, you could certainly just add all the spaces and such yourself, or you could use `virtualedit=block` and vim will add the spaces for you. But you'd never know about the option beforehand because you didn't need it before.
Those benefits only became apparent after about a week of forcing myself to use them + some minor tweaks.
Can't say it made me any faster or more efficient, but it sure does feel satisfying and more comfortable. And, let's be honest, it also makes me look cool!
I've used Neovim since it first came to and there are good reasons to try it out:
- Native Lua support. While you don't have to rewrite your config in Lua, it's a big boon for plugin writers.
- A very active community, fueled by.Lua being so much nicer than vimscript.
- Native LSP support. Granted, you can get similar features from plugins such as coc, but the native integration in Neovim feels a lot more integrated and extendable.
- Treesitter support. Fast and more detailed syntax highlighting is nice, but you can also do more contextual transformations like swap functions or function parameters regardless of formating.
Plenty of people still use Vim; probably more than use Neovim (just a guess). Now that Vim has asynchronous plugins and terminals, there won't be much difference for you unless you want to write your own plugins or elaborate configurations: you can do that in Lua with Neovim, which is much saner than using Vimscript. The only other reason might be if you want to use a plugin that’s not available in Vim.
I have considered using neovim but still haven't made the switch. I really wish there weren't the two options yet here we are. One hand, while I very much respect that Bram can do what he want (and he's done so much for everyone), it's still pretty lame how it all went down that led neovim to come into existence. But ya, I dunno, I still just use vim.
I also actually like vimscript—Sure, it's 100% Stockholm Syndrome, but still.
I kinda use both. vim and my ~/.vimrc have all my sensible settings and keybindings and leader keys stuff and stays lightweight, good for just text editing or reading whatever quickly. no plugins at all really. For neovim I tried to go for the whole VIM as an IDE thing, any plugin I use is installed in it, it attaches to a few LSP servers, etc etc. Also my neovim init sources my .vimrc, so any basic keybindings I like come over there too.
Some people seem to love the lua angle to neovim, I don't really know anything about the language, I get that it allows for more powerful stuff, but it's also ugly as hell and it seems like it always takes like 34875982345 characters and 700 curly braces to just do imap jk <Esc>....
I also use vim not neovim. I don't like the neovim culture and money grab. I think the founders misrepresented the origin story. But neovim does have some nice features. But not enough for me to switch and vim is being improved at a rapid pace. Still team vim.
For those that are whiling to learn vim, I recommend to not install a lot of plugins when you are still learning, you will probably just forget them and it will probably have side effects on your configuration!
But as basic plugins that will provide a great quality of life, I shall recommend those:
I wouldn’t recommend nerdtree. It’s good at what it does, but what it does is not a thing that people should do.
Finding files is much faster with a fuzzy file finder, and displaying the file tree (which I think people typically need way less often) can be done by backgrounding the vim process to drop to the shell, running `tree`, and foregrounding again.
An important conclusion I once came to, which I am sure many others have found out for themselves: while an IDE may help you edit code, and vim may work well for you as an IDE, vim’s core competency is much more fundamental: it is as a text editor.
One is most likely to conclude this when using an IDE and wanting to juggle some prose in a comment. What
would have been so simple in vim is a little bit harder in your Monaco based editor. A happy environment is one where vim is never far away, no matter what you are working on.
I tried out vscode-neovim at one point but switched back to vscodevim. I don't actually remember what the problems were but I do remember thinking that vscodevim was the lesser evil. It's pretty hard when coming from regular vim, but I live with it. But maybe things have changed?
Post 0.5 neovim, vscode-neovim is great, well for me it is. But there were three problems.
Command mode sucked but it's much better now. If I could close the results window with an escape character, that'd be just great.
If you navigate right with the space bar, it screws up the line. Right arrow works fine. However, I think this is a VSC problem. :e! fixes the problem.
If you do any editing immediately after opening, it just inserts your keystrokes at the beginning. It would be better to buffer or ignore them. I also think this is a VSC problem. :e! fixes the problem.
I only added clangd very recently. It obviates You Complete Me, ctags and much of clang-tidy. It refactors. It's an awesome code navigator.
Thank you. Maybe I should give it a try again. I am also frequently considering creating a vscode extension that just opens a file in a terminal-based vim instance, sitting in a tab. I think that would be possible and it would be a nice fall-back..
That's also my setup. I find VSCode Neovim can get out of sync at times. The fix seems to be to close the document and re-open it. Not knocking the plugin, it has to be quite the task to get the integration working perfectly.
I have this out-of-sync issue as well. I was previously blaming it on a Clojure plugin (Calva), but I'm guessing you don't have that. Wish I could reliably recreate - it happens once or twice a day.
Vim and Emacs are an investment, but the investment pays off ten fold. On top of their powerful features you get to support free and open source software that isn't being steered by corporations that want to keep you locked in and collect as much analytical data on your habits as possible. They aren't looking to lock you into an editor as a service. We've seen with neovim that the system works and has made both vim and neovim even better through healthy competition. Free and open source for the tools you use everyday is the way to go.