I've been using vim for years, switched to neovim, and at this point I'm ready to throw in the towel and just use vscode for anything beyond simple text editing.
The amount of work needed to get a basic IDE up and running for your languages of choice, even for commonly used languages such as Python or Javascript, is far too much for someone who wants to get on with their day job or hobby coding and doesn't want to spend precious hours fixing obscure issues in Lua.
Furthermore, the community does not have a good culture of documentation and learning: too many plugins have very sparse docs, and other online resources such as the Neovim subreddit are hostile to newcomers with "RTFM" a common answer. The community is also fragmented, with too many ways to do the same thing in the name of some platonic ideal of personal freedom over practicality.
A simple question like "How do I set up Black with neovim to format my Python files on save?" will yield a dozen answers, each one with someone's favourite plugin. Setting up that plugin will require another plugin, and so on until you end up with a Jenga tower of dependencies that doesn't quite work the way you want, but is too fragile and time-consuming to tweak correctly.
In the meantime, I can just Ctrl+P and install what I need in vscode and be on my way in a few minutes.
I don't particularly like vscode. It's heavy and slow and janky, particularly on older laptops. I don't like being sucked back into the Microsoft ecosystem after spending years getting away from it. But ultimately, I want to just get on with my job, and my job is not Lua Developer or Neovim Plugin Expert.
> The amount of work needed not only to get a basic IDE up and running for your languages of choice, even for commonly used languages such as Python or Javascript, is far too much for someone who wants to get on with their day job or hobby coding and doesn't want to spend precious hours fixing obscure issues in Lua.
"This airplane is the choice of professional pilots! The first thing we advise you to do is turn the yoke upside down, it's much more ergonomic like that. Also, you probably want to rip out the altimeter and replace it with a custom one that has more features. And bring your own GPS unit and tape it to the windshield, because this plane doesn't have one by default. And of course, remember that unlike in your car, 'left' actually means right in this plane. This is the professional way. Ah yes, when you fly over Canada, you will see a blinking warning sign telling you that you're out of fuel. That's just a small glitch caused by metric/imperial confusion. It has been known for 23 years but we haven't quite gotten around to fixing it yet. Don't worry, this plane is still excellent for professional pilots. If you feel otherwise, you are probably not a real professional."
More that you want to carve a bowl out of wood. Vim is like a knife that with some modifications you can turn into a carving knife. VSCode is like a chainsaw that has attachments that have been made for it and it also has bowl carving attachment.
If you don't know your tools, then you can easily mess the knife modification and not end up with a carving knife. The chainsaw with ready made attachments is way easier to get going, but in return you have to carry the chainsaw with you and if there are any problems with the tool itself you probably aren't going to be able to fix or modify it yourself.
So it is more like trading initial speed with more precision, but also being able to do more after the initial learning curve.
> The chainsaw with ready made attachments is way easier to get going, but in return you have to carry the chainsaw with you and if there are any problems with the tool itself you probably aren't going to be able to fix or modify it yourself.
This is where your analogy breaks down for me. The "chainsaw" (VSCode) is absolutely perfect for the tasks I'm using it for. When I write Python code, the Python extension gives me exactly what I want. That's because the environment it creates has been fine-tuned based on feedback from thousands of users with similar requirements to my own. There's no need for me to modify anything, any more than I modify my car or my trousers. It's simply ready for me to do professional work, and whenever I have special requirements, I know that I will find an extension that caters to them also. I don't need or want to reinvent a wheel that has been invented hundreds of times already, and polished to perfection through more man-hours than I could ever hope to invest myself.
You get exactly the same functionality with (neo)vim plugins.
Only difference is that because vim has been open-source for decade, there are many many more plugins, and hence the choice is harder to make. VSCode also helped improve the (neo)vim experience (e.g. language servers)
Comparing VSCode and Vim is like comparing a standard calculator with an RPN one.
> Only difference is that because vim has been open-source for decade, there are many many more plugins
No, the main difference is in the quality of plugins, not in how many there are.
For example, Rust-Analyzer provides an official VSCode extension, which is professionally maintained by members of the Rust core team. The extension is part of the Rust-Analyzer project itself, and can be installed with a single click, at which point it just works.
For Vim, you have to manually download (and update) the Rust-Analyzer binary, install a third-party plugin, configure them to work together, and hope (1) that the whole thing doesn't break when the plugin or the language server is updated, and (2) that this concoction provides a tiny fraction of the functionality that the official VSCode extension does.
FWIW, I just needed to install the default nvim-lspconfig plugin (it's provided by the Neovim maintainers, and it doesn't do anything besides provide default LSP server configs for a lot of languages to the builtin Neovim LSP client), paste in the keybinds recommended by the README, and call lspconfig.rust_analyzer.setup in init.lua. Configures itself to start whenever rust_analyzer is in PATH. Seems to work well enough! I don't think it's missing any functionality.
I agree with your main point, you have to do quite a few things to configure these plugins and some of it is not straightforward.
However, I program rust using the lunarvim default configuration for vim and it has been very straightforward. I have all features I need to program comfortably and I didn't need to configure anything, the defaults were good enough for me.
So that doesn't mean that vim cannot have the same easy of use if there exists some sane default configuration you can just install.
I am happy with it and not going to change to vscode or something else.
I'm a vim user, but only because of the keybinds. I use VS code an equal amount because I often get too frustrated trying to wire the disparate vim tools. The never ending fiddling and 30-step process to get the equivalent of one click in vs code is exhausting.
The people who _enjoy_ the toil seem to truly struggle to comprehend that someone might not want to spend hours upon hours learning how to get things working, only to immediately forget.
> The people who _enjoy_ the toil seem to truly struggle to comprehend that someone might not want to spend hours upon hours learning how to get things working, only to immediately forget.
One of the tips in The Pragmatic Programmer is "Achieve Editor Fluency", wherever it's Vim, VS Code, or Sublime Text. I use IDEA for java code because in my job, I browse code more often than I edit it, and IDEA is nice for that. I also use WebStorm for the JS part because it's also good for that. But I invested my time into VIM because I can do everything above with it and even more. I don't want my editor to become an IDE, I want it to be powerful in editing and allow for integration, as there are slews of tools that work with code and text.
You should invest in your tools, be it Vim or VS Code. I chose Vim and Sublime Text because of their speed, and JetBrains' IDEs because of their code analysis engine. You may have different criteria, but try to follow the tip.
I do exactly what you described and indicated that clearly in my post.
What I'm perturbed by are the people who take it to extremes, and are happy to spend hours a week tweaking things, and can't fathom someone else might not enjoy doing the same.
> The people who _enjoy_ the toil seem to truly struggle to comprehend that someone might not want to spend hours upon hours learning how to get things working, only to immediately forget.
It's worse than that, it's a religion. Many of them truly seem to believe they're achieving a higher "hacker rank" or something, while most of it is just tedium and very low level learning.
It's rarely learning huge, game changing concepts. Frequently it's just chasing obscure docs to obscure forums to obscure repos for stuff some PhD student half baked a decade ago on their way to their biochemistry thesis.
Guess what, I work in DevOps, that's just my dayjob, anyway, I don't want to do it as a hobby in Vim, too :-))
And I say this as an "also Vim user". I.e. I use Vim and I've used it for more than a decade, just not exclusively, best tool for the job and all that.
For what it's worth, the 'VSCode-level' functionality in my init.lua has probably required roughly a few hours of maintenance over the ~7 years I've been using Neovim. The LSP setup is just a matter of finding a plugin manager (or not), installing the lspconfig plugin, pasting in the config from the README, and inserting a single line that contains the name of the language server you want to configure.
It can definitely lead you down all sorts of twisty paths if you look at other people's elaborate configs and decide to do that sort of stuff yourself but it's very pleasant/low-maintenance if you stick to the basics (meaning roughly what people do with VSCode). It takes me roughly a few minutes to configure Neovim for a new language :)
(Of course, there's some other stuff in my init.lua that I've put there for fun, like clipboard and window management scripts, but that's not strictly necessary. I've spent a bit more time figuring out the Lua API to write these, but I personally think it's worth it for the extra ability to mold the editor to my needs).
> No, the main difference is in the quality of plugins, not in how many there are.
I don't think that is true. If you browse the vscode marketplace and search e.g. for python [1] you literally get hundreds of plugins. If you scroll down only a bit, you quickly end up at plugins that only have a few hundred to a few ten downloads. I highly doubt that the quality of those plugins is better than the plugins for (neo)vim.
For your Rust-Analyzer Plugin example: I can install Rust-Analyzer with Mason in a few seconds as well and then (if you have lsp-zero [3] installed) it also just works™.
But I agree, keeping a vim configuration up to date is akin to a hobby (which I by the way enjoy quite bit).
That's just plain untrue. Vim always kept its own rust-analyzer binary and prompted me to update it. I use emacs now and actually have to update it myself
If what you need to do is cut down bunch of trees then chainsaw is exactly what you need. No one in their right minds would start with a knife and start building it into a saw and then attach a motor to motorize it. Mind you we were carving a bowl, but as per Internet argument you completely dismissed the use case and inserted your own.
If VSCode does exactly what you need out of the box exactly how you want it to do it, then you are set and you should use VSCode.
The problem is that Vim can be used to create config files and source code files among other things. VS Code can be used for very much the same things.
The output of both tools is practically the same thing.
The niche of things Vim can do and VS Code can't is tiny and constantly decreasing.
It's always been like this. Vim is an editor, and so is Sublime Text, Emacs, VS Code, Geany, Kate, Notepad++, and more. What sets vim apart is its ubiquity (it's been on every Linux box I touched) and its philosophy of editing text (modal editing). Apart from that, it's a matter of preferences and practicality.
I can think of a few YouTubers who would and probably have done just what you described. Now that I say that though, I realized you used the phrase "right mind" and I don't think I'd count many if any in that cohort.
Nah vs code is a multitool with both a hook blade (the knife younuse for carving out a bowl) And a chainsaw....
Slightly more unwieldy in that specific narrow use case than a plain hook knife but you don't need a second tool to cut the log you take the wood for the bowl from...
In other words, it's a tool that let's you do near anything with minimal modifications whereas vim is a tool that requires significant modification just to do Any task other than looking at it.
Yes. The advice to turn the yoke upside down is supposed to reference remapping Caps Lock to Escape, without which Vim destroys your pinky on a standard keyboard. But it's the choice of professionals, so what can we do?
I've been using Ctrl-[ instead of Esc for so long that I forget that a lot of people don't know about it. This may not be convenient on non-English keyboard layouts.
small fun fact:
I switched to this when the escape key was taken from me (thanks again NOT apple)
After switching to a newer MacBook that has the escape key I did not start using that again, but stuck to the Ctrl-[ as it just works.
I'm playing into the joke here, but on most terminals, alt + <key> will actually be sent to the program as <esc> + key. You can use this to avoid pressing escape in Neovim.
+1. I mainly use this approach. If your next intended move is to go to the next line, Alt-J will exit insert mode and go to the next line immediately.
Also the same for Alt+w/W/b/B, Alt+o, Alt+0, etc etc and it's just a matter of using your left thumb at the same time as navigating.
Nice, I didn’t pick up on that one. And I do have Caps Lock mapped to remapped to Escape haha.
If any vim enthusiasts haven’t read this history before, this article [1] provides a good overview of how ex/vi came to be. The photo of the Lear Siegler ADM-3A keyboard used by Bill Joy largely explains the odd choice of keys.
Trick for those wanting caps lock to be compose instead: ctrl-c also works as escape, and has historically been slightly faster due to sidestepping the escape timeout.
There is a timeout on multi-key mappings, so if you need to type fd0 you type f, wait 'timeoutlen' (1 second by default apparently), then type d0.
That's a pain, but it doesn't come up often. In return you get quite a lot of functionality (due to vim being modal) without having to move your fingers beyond the letter keys, which is quite relaxing.
Like many things in our field, we try to justify our choices, and because generally folks in our field holds high standards about themselves, we should justify as the only right way. What in reality, it is all about user preference.
In the end, use whatever your feel most comfortable. I hate the VSCode interface and all of those notifications/popups and general slow interface, but I can understand who doesn't care or think that even with those VSCode is still more efficient for them. I also can completely understand the issue that folks say when they lost a long time tuning their Neovim configuration to their preferences, considering that I just have done so. But I still prefer neovim to VSCode nowadays, and not everyone needs to think the same, and this is fine.
I take it you've never played a fast game with keyboard controls? :-)
They could have laid out the arrow keys WASD style. One up, one mid-down, two to the sides.
Nobody said they had to use dedicated arrow keys. Just lay them out like a normal human being. Whatever key for up should be up, whatever key for down should be down, whatever key for left should be to the left, whatever key for right should be to the right.
In the specific case of text editing with vi bindings, having up and down on the same row is more convenient, since you don't have to move your fingers to perform linewise vertical motions (compared to a standard WASD "grip"). Navigating within a line using left and right is uncommon when using vi bindings, since there are usually better ways to jump between locations within a line, so it makes more sense to pay the cost of having to move your fingers in this case.
Not only that, but I posit that any context that uses vi-style binds uses vertical motions much more often than horizontal ones (pagers, editors and other applications with vi bind ports, etc.).
As for games, whilst WASD might be more intuitive, it is technically inferior in tactical shooters, where having the W and S keys on the same column means your (admittedly somewhat rarely used) forward-motion counter strafe will always have an inherit delay due to having to move your sole finger dedicated to those two keys. In this case, vi-style ASDF is again marginally better.
That being said, your gripe seems to be overstated, if this is your biggest problem with vi-style binds.
> That being said, your gripe seems to be overstated, if this is your biggest problem with vi-style binds.
I like their composability and I'm generally fine with them, the real Vi problem is just... bad embeddability. Almost none of the apps that I'd want to use with Vi bindings support them to a native Vi level (Firefox - it used to support them well but then they killed the extensions; shells with Vi support only have half baked support, same for IDEs, let alone stuff like Outlook and whatnot :-) ).
Their lack of ubiquity will always doom them to a niche thing used by devs and sysadmins, sometimes, and only by some of them.
This is a point I completely agree with. Firefox is the perfect example of a context where you would want vi binds, but the implementation ends up being half-baked.
The fun part is when web apps like GitLab, GitHub and my email provider provide their own keyboard-centric, vi-style navigation layer, and I have to compromise between either using my browser extension's vi layer or the web app's one.
Nyxt and qutebrowser try to tackle this by offering a native, keyboard-centric, vi-style navigation model - though neither is (yet) a full-featured replacement for Firefox or Chromium-based browsers.
For IDEs, I find the emulation to be alright for basic editing, falling apart soon after. There is an implementation for VSCode that is actually pretty good, as it makes use of Neovim as a backend server - though, it's of course not perfect, and customizing it is a pain I imagine.
Perhaps somewhat ironically, Emacs's evil mode is the best vi layer implementation I've used - probably mostly because customizing it in elisp is much nicer than interfacing with arcane vim APIs.
The vi emulation really is only as good as the implementation. The problem is that it has to be reimplemented for every context, and made to play nicely with the limitations and edge cases of said context. This is, of course, a lot of work.
Check out Qutebrowser. It's almost entirely usable from the keyboard only using vimlike bindings. Lags behind chromium/qt a bit for the actual engine, but these days it's totally usable and has become my daily driver.
Did you read my original comment? I literally mentioned QWERTY as another example of backwards compatibility screwing everyone over.
I use QWERTY because I have to, I don't like it and I can't do much about it in practice. People frequently defend Vi's HJKL vehemently - just like - if I'm not mistaken - you, presenting it as a superior option for some reason.
I actually switch back and forth and I've thought many times about remapping u and l and j and k... you know what, maybe I should just bite the bullet.
HUJK instead of HJKL, basically WASD moved to the right :-)
Yeah. I actually find that no highlighting in some ways helps you understand the language better. Because you have to parse it, not rely on the highlighting to do it for you. When I was learning Rust, I spent a year writing Rust in vanilla vim which is by some accounts insane. But I did it for the uh immersion. And I’m happy with the result.
I do use Zed for working on projects when on my home turf. It’s just that I’ve sworn off wasting time configuring Vim everywhere. That too is advantageous because you have to have a much more thorough knowledge of the vim tool instead of relying on plugins to make it work for you. And vim is everywhere.
The thing is, using a plugin like ‘surround’ Is just so nice. When you’ve chosen to use a pleasant and powerful editor, I don’t see the benefit in depriving oneself of further pleasure and power.
I use vanilla vim when I have to ssh into a server and work on some config files. As such, I much prefer it to nano, and it's installed, or easily installable, on any Linux server.
For that use case, it's absolutely great. No complaints.
I spent years and years enjoying using vim for the same purpose when I was a sysadmin. I was absolutely disgusted beyond belief to find out people actually used it as their daily IDE when I became a developer.
Let's not forget that vim isn't really designed to be an IDE, though. People just like the editor so much they want an IDE with it. Unfortunately using vim itself for that is the wrong choice. The correct choice is emacs with evil mode.
The correct choice is to instead use something that doesn't require a really long time to both learn properly and modify until it's decently functional, even including premade distributions for it, and just using something to get the job done so that, you know, you get the job done instead of preparing to get it done and not getting it done.
Referencing the Gimli glider. But does vim have any analogous issue? In matters of technical correctness FOSS is usually the more exacting. You won't find a 1 TB hard drive full at 931 GB of used space on Linux, for example.
This was supposed to parody how some of Vim's default shortcuts just flat out do not work on non-US keyboards, because e.g. typing [ requires pressing AltGr+8 on German layouts, but Ctrl+AltGr+8 is not the same thing as Ctrl+[.
And yes, it was also a reference to the Gimli glider.
I'm Czech and I use the English layout with UCW accented letters accessible via AltGr. It's much more convenient than tke standard Czech keyboard, even outside of Vim.
>The amount of work needed to get a basic IDE up and running for your languages of choice, even for commonly used languages such as Python or Javascript, is far too much for someone who wants to get on with their day job or hobby coding and doesn't want to spend precious hours fixing obscure issues in Lu
Can't agree with this at all.
I don't think I've spent more than an hour in total setting up my vim config back in a day and maybe 1-2 hours in total when migrating to neovim (lua, packer etc) and then migrating to Lazy.
Yes, you have to spend some time building your own DE, but at least now you know what it can really do, all the hows and whys.
>Furthermore, the community does not have a good culture of documentation and learning
Most of the plugins have docs that can be accessed via (neo)vim itself. Usually you can find all information there.
>Setting up that plugin will require another plugin, and so on until you end up with a Jenga tower of dependencies...
Not true at all. Only a few plugins have strong dependecies and even then you rarely come across a plugin that will have more than one dep.
Haha 1-2 hours ... Maybe things have improved since 2018 but I was up to about 25 hours and still not satisfied with the results. That might be just being a perfectionist or coming from another IDE and trying to replicate something. But 1-2 hours is not a reasonable amount of time to set aside to set up a truly usable custom ide with neovim to acquire the knowledge to drive it.
I’ve plugging away at NeoVim in my spare time trying to get it working and it took me a weeks before I just gave up and directly ripped someone else’s LazyVim config to finally get things working in a state I’m happy with.
Never mind that in order to get modern syntax highlighting and code completion you need LSP-Server, Mason, and Null-ls. The first which has per language dependencies and the 3rd is about to be archived.
Also I don’t know what world you live in but a tool a verbose and powerful as NeoVim you can spend hours just reading the documentation and getting a handle on the basics let alone configuring things to your liking
null-ls is now archived so you don't need it (dark humor). Anyway - you needed it for linting\formatting etc.
Modern syntax highlighting comes with treesitter, you don't need anything but theme that supports it.
You also don't really need Mason unless you want an automated way of managing your providers. And LSP-config+Co is needed anyway - neovim\VSCode and other editors use it all the same.
>Also I don’t know what world you live in ...
We were talking about building a config, not about learning every dark corner of it. You don't have to go much further than Packer's or LazyVim readme.md to get a grasp of what's going on. Things were much harder when it was vim and vimscript + some plugins.
> Most of the plugins have docs that can be accessed via (neo)vim itself. Usually you can find all information there.
This was something which took some time for me to notice.
There are some plugins which have the best documentations I have ever seen, but you need to read it from the Vim.
I vehemently disagree with this. I find managing vs code extensions a nightmare and having to download them based on rating alone when there are 300 extensions for every query is untenable in a production environment.
Furthermore if you want to customize a vsc extension to do something unique for your set up you have a whole new set of issues like finding the settings, documentation etc.
Now if you can get over all of that it’s still a bulky, slow and cluttered IDE that is constantly sending telemetry data and other nonsense around the web
While I haven’t tried LazyVim I would strongly recommend LunarVim to anyone new to the vim ecosystem. It installs fast, needs minimal set up and packages can be installed with a single line in the config or through packer. Most things work out if the box. But if they don’t vim is so mature you can just ask chatGPT.
Seems like ease of use is also the aim of lazyvim so I would not discourage anyone from trying this flavour as well.
After an unfortunate bout of Java development, I was flung into the arms of Intellij, steadily won over by the indexing and the reliability of the refactoring tools. The Vim plugin was good enough and defining some chords for editor shortcuts resulted in a kind of fucked up fat vim emacs mode that was quite productive.
I, too, got fed up of spending inordinate amounts of debugging vimscript and incompatibilities to end up with something that was slower or buggier than an IDE in certain crucial ways or with highly debugging resistant niggles.
But I'm also far from in love with Intellij these days. It's slow. Prone to index corruption with lots annoyances I can't easily fix myself. I may churn to vscode. But I'm definitely in the gravity well of Intellij.
However perhaps this is worth a look. I have historically had a fairly high tolerance to plowing hours I'm never getting back into fiddling with tools. Just less than I used to. More nixos gnome, alacritty than gentoo, xmonad, urxvt...
I spent quite a long time trying to get nvim-jdtls configured correctly and playing well with all the other LSPs I have configured. Had it mostly working and I did like writing a large amount of Java for a greenfield project in Neovim, but then a bunch of it broke again when I upgraded either nvim or one of its plugins. So I spent some time trying to make the IdeaVim plugin work as closely as I can get it to my Neovim setup and am finding that to be a happy medium. But I might still come back to Neovim for raw editing at some point if the LSP issues do get sorted out.
Same. IntelliJ is just too damn good for JVM work, and specially for Kotlin. jdtls ans other Java langservers are decent, but unfortunately, kotlin_language_server is miles behind IntelliJ.
Not only that, but in my experience everyone else will be using IntelliJ, so the project is usually dependent on IntelliJ in some form. Sometimes subtlely, sometimes not so subtlely. It will usually build with gradle since it has to for CI/CD, but beyond that everytime I worked on a new project I had to fix all kinds of subtle problems that were the result of some config/state that IntelliJ keeps outside the repo and nobody notices because they all use IntelliJ.
I somewhat like Intellij too, but it seems insanely slow, esp. with the Vim plugin. I have to slow down my editing sometimes, because all it's fancy features can't handle the speed.
When it's having a particular bad day I can sometimes rename a file-local unexported symbol faster than it can (pointlessly) search the entire repository for the name. Or when it's on an indexing holiday I can navigate by memory to a file I want with mouse-and-tree faster than it can. This make me sad and feels more common than it used to.
FWIW, I still use regular vim with ale [0] and it does everything I want. It formats files with Black and isort, shows ruff and pyright errors, supports jumping to definitions, and has variable information available on hover. It also does this for every other language I write in. I have collected my config over the past several years, but I pretty rarely encounter errors with it. It requires no additional dependencies except for the language tools themselves (Black, ruff, etc.).
This is the problem though: if you come to Neovim, and ask "what is the best formatter/linter" someone will tell you "use null-ls". Then a dozen others will say "don't use null-ls, it's been deprecated, use efm-langserver".
OK, how do I set up efm-langserver with Neovim? Good luck! You could probably use a plugin, or maybe not. You'll need a way to install LSP servers. nvm-lsp-installer? Nope,that's also deprecated, use Mason. OK, MasonInstall Black. Wait, it's not formatting anything. Oh, you might need nvim-treesitter. Um...ok, but that's installed already. Ah, you just haven't configured it correctly...here is my setup (pastes 300 lines of Lua or vimscript with zero context as to where you are supposed to load it)....Why are you using efm-langserver? Formatter.nvim is all you need! What? That's old hat! You should be using neoformat!
If you mention Ale or coc.nvim...they stare at you as if you have just stepped out of a time machine from the 19th century.
I see where you're coming from. FWIW, I've been using Neovim for an odd 7 years or so and only use plugins where absolutely necessary. I'll usually just add an appropriate BufWritePost (trigger after saving the buffer) autocommand for the language's file extension that does what I want. Or I'll add a keybind in .config/nvim/ftplugin/<lang>.vim (or <lang>.lua). You can do fancier stuff with plugins but I find that I just don't need it (and you probably don't either, by the looks of it).
The default LSP client config at https://github.com/neovim/nvim-lspconfig#suggested-configura... sets everything up for you, if you're using an LSP server. I'm not sure why it hasn't been merged into the Neovim repo; possibly because they want to keep the editor core fast and minimal.
All this means you have to do a little more configuring than with something like VSCode, but to be honest, I haven't legitimately needed to make big changes to my config in a few years. There's stuff I add for fun (like little lua scripts to manage my clipboard and to layout tabs the way I want), but to maintain a 'VSCode' level of functionality none of it's needed. The advantage of spending a little extra time, for me, has been that my editor 'fits like a glove', so to speak :)
So basically your problem is feeling insecure because other people do different choices.
I didn't care following all the trends, my setup use coc.nvim[1] and I don't have any problem with that. I don't care about black, I am fine writing python stuff without it.
Your setup doesn't have to be complicated because others is.
The problem is when you are a newbie to a space, you don't know the difference between "cool" and "what is the best practice as defined by the experts".
I'm a huge Neovim user, but the amount of "hey guys I just rewrote this perfectly fine plugin in Lua [for the Nth time] check it out" posts every day are tiring.
I’ve definitely been down the Vim config rabbit hole and struggled to find the right balance between “cool” (actively developed with newer features) vs. “best practice” (more mature and stable). My current approach is to search Hacker News comments for “vim plugin-feature-I-want” and the most popular comments usually point me in the right direction.
For what it’s worth, I use Neovim with ALE at the moment and it works just fine.
I have also been able to program for years in C with vim + ale + gutentags but if you start doing some web with all its litlle dsl, it gets overwhelming quite rapidly. In this case LunarVim (or others) is a relief.
> The amount of work needed to get a basic IDE up and running for your languages of choice,
I don't think vim is meant to be an IDE. If you want an IDE, go get an IDE. If you want a text editor, vim works well. But vscode is unwieldy as a text editor, and vim is painful to contort into an IDE.
Exactly this. Don't blame the airplane for not being a car, or a submarine for being a beach buggy.
Obviously people have made things for VIM to be IDE like, some are cool to me, but completion-integrations-lang-servers always seemed so anti-vim to me. Make an HTTP request every key stroke to get suggestions? The. Latency.
Then tell the vim fan bois to stop telling people to use vim as their ide....
The issue isn't with the fact people try to use it that way, it's that those who use vim are adamant it's the best option for doing so and berate the Other until they try.
not really..
vim is easy to extend and adapt.
You loose that with only vim mode in vscode.
You also loose the ecosystem and relevant core functionality like most vim core functionality like :grep :vim :make, quickfix list, arglist etc..
I dont know..
The argument i read all the time is "i don't want to invest time in vim".
But what kind of professional spends hours uppon hours learning his craft (programming), but is unwilling to invest some of those hours into mastering professional tools?
What about sharpening the axe? The amount of time i saved by sticking to vim is definitly more that the time i needed to learn it..
IDEs are easy mode and waste of resources.
Its ok to start with them as a noob, but down the line i want to customize every part of my toolchain. (And thats just horrible to do in VSCode etc..)
If someone likes to use vim, then so be it. If someone likes to use VSCode, then so be it. IDEs can also be called productive mode and use the right amount of resources necessary for large projects. They will get the job done, and for many it is the preferred option.
Vim doesn’t have to be the tool you use when there are others. If it was the only tool, I’d agree that people should know it better. Thankfully it’s not the only one.
Some hours is not what one should put into Vim, IMO. I've used it for many years and felt I got better at it very gradually (maybe I'm like that with most things). It's much more than hours! It's using it every day for a few years :)
I think your experience report of the NeoVim subreddit is severely misrepresentative of reality. I have never seen a RTFM response. Many answers point to exactly which part of the documentation would be helpful. Your Jenga tower of dependencies is much more imagination than fact.
If you want Black to format your Python files on save, write an autocommand. That's what they're there for. If you need help to do that, ask for it.
Or if you don't want to take the trouble to learn how to use (neo)vim, then don't use it; that decision is fine too.
> If you want Black to format your Python files on save, write an autocommand. That's what they're there for. If you need help to do that, ask for it.
The real question would be:
Why does the 50 year old editor with supposedly a huge community and tons of editors not have support for a popular formatter for probably the most popular programming language on the planet, and instead everyone has to write their own (probably buggy) variation of that integration?
It does, you'd just have to install a python plugin that registers the autocommand-- or leave out the plugin and register the autocommand yourself. The (n)vim/emacs communities aren't fond of integrating the hot new thing for each language directly into the editor-- I think this is a lesson that comes from being 50 years old!
As for whether it would be buggy, I'd doubt it? Unless Black's principle of operation is different from most formatters, it should just write the formatted contents to the file, right? The autocommand you'd use would just run Black on your current file on each save. So where % is Vim's symbol for the name of the currently open file, :silent! suppresses stdout/stderr from the formatter, and :! runs a command:
autocmd BufWritePost *.py silent! !<format_cmd> %
(Don't quote me on that, but it should be essentially correct. I'm not at a computer right now.)
Actually, it looks like you can install an (n)vim plugin from the official Black repo here:
Anyway, I think it's actually a really cool effect of doing this that you realize a lot of the scaffolding underneath most editors _isn't_ that complicated! It's totally understandable :)
Because it's been here before the formatter and will be here after it. I don't think there is any support for any formatting tool, except the general act of formatting for every formatting tool. And if you find your config has multiple lines just to format languages you've touched, then it's time to build a plugin or search for one. And if you find it, and it's quite not like you want, extend it as most plugins are open source and free.
If the tool doesn't suit you, build your own or find another.
> I don't particularly like vscode. It's heavy and slow and janky, particularly on older laptops. I don't like being sucked back into the Microsoft ecosystem after spending years getting away from it. But ultimately, I want to just get on with my job, and my job is not Lua Developer or Neovim Plugin Expert.
Personally I've started paying for intellij and using it with it's vim emulation. I know it doesn't solve the problem of being clunky on older laptops, but it is an amazing experience to use. I get the best of both worlds, I get really good vim emulation so I don't have to relearn editor shortcuts, I get the benefits of a modern full fledged IDE with many useful features that work out of the box with basically 0 configuration (debugger, git, tasks, etc.)
Same. I like it better than the vscode vim emulation, which is more “strict” and turns to the visual mode when selecting anything with the cursor. Which I personally think is the worse part of vim.
I do have a personal all-products license as well, but I hesitate to go “all in” and be dependent on them.
But it is ok to just use a lot of editors for different things. VS Code is ‘good enough’ a lot times. I like writing notes in emacs org-mode. NeoVim on the command line. Sometimes I use Helix, I think it hits a sweet spot between snappiness and minimal configuration.
If you want IDE like features, then of course an IDE is a better choice. I've never understood why people and to extend vim to try to make it half of an IDE.
JetBrains product has always been fast for me, as I wouldn't run them on a 10-year-old computer with an HDD drive. They've been very configurable, more than other IDEs I've used. An IDE is a host of tools, so the UI can be dense because they can do so much stuff. You invest in your tools, and that can also mean buying a powerful enough computer to do the stuff you want.
> the UI can be dense because they can do so much stuff.
Vim can do a lot of stuff, but its UI is very minimal. That's because it recognized that there are already many buttons right under your fingers, so there's no point in putting more of them on the screen.
Vim has the potential to do a lot of stuff. It is extensible to a point that you can build any JetBrains' IDE with it (their main selling point is the code analysis part). But right out of the box, editing is its only strong point.
GUI is more discoverable than terminal software. You open a project with WebStorm, it can already understand it, and you can configure a build process in a few clicks.
i share your feelings and i'm a happy jetbrains customer (and i dont do java!); but i see the point of people not feeling comfortable using them specially when coming from more pared-down experiences. emacs and neovim are also snappier, vscode is marginally snappier, doesn't bother me but it's noticeable.
JB also has some glaring holes, like the inability of easily specifying an env file to load when running projects from the IDE runner (and the plugin to do this was half broken with the 2023 versions)
The 'New UI' in PyCharm 2023 is pretty nice. Less of an airplane cockpit vibe. Its still a total hog of compute resources but I have an M1 machine and never notice any problems.
For many people, it's because the choices for an IDE are all dog slow, and configuring a few plugins for their editor of choice provides a close-enough experience to strike the balance they are looking for.
So, no, an IDE is not a better choice for everyone who want's "IDE like features". It is for some, but not everyone.
> I've never understood why people and to extend vim to try to make it half of an IDE.
Because vim ships with any *nix machine and provides a consistent experience no matter where you use it.
Vim is the DE part and people add plugins or whatever to enrich the text editing experience with LSPs or other language aware plugins, and the I in IDE is in the form of the integration with the tooling already available on the host.
I feel you, but I’d like to point the Finger in the other direction as well: (modern) programming is not sane. The tools and the environment are not made to be sharp and minimal, we are not using hammers and screwdrivers, we are all using custom made chainsaws with hundreds of proprietary extensions and that’s about as minimal as it gets. Sometimes it’s actually more like wielding multiple nunchucks each covered with chainsaws.
It’s quite disappointing we need multiple layers of assistance to even begin our work. Syntax, autocomplete, go-to def. These sound like simple things, but are fiendishly difficult. Catering to all the various languages’ their idiosyncrasies is, as you have noticed, a task beyond the community.
If something like editing some basic pieces of code takes multiple man-years to facilitate and requires “language servers” I tend to look towards the environment that produces such monstrosities.
Maybe we could stop complicating things so damn much? Impractical I know, but I won’t give up an ideal just because it can’t be reached (now).
Instead of syntax highlighting do you want… minimal syntax in languages?
Instead of autocomplete do you just want to type the thing out manually?
Instead of go-to def do you just want the code in 1 file?
These things didn't require language servers historically, but LSP was an attempt to reduce "many editors re-implementing the same functionality many times" to "implementing the same functionality once and connecting many editors to it". This has a cost, and YMMV on the docs for getting LSPs set up, but I don't think I'd prefer going back. I don't use it, but it seems like VSCode has 1-click plugin installs for most of these LSP integrations, more or less?
Notice I said these features sound (and should be) easy, but they are not. The “intellisense” features themselves are fine as QoL improvements.
It’s the environment and the languages themselves that produces these “problems”. I mean, let’s say, Python. I just don’t know what to say to you if you think sanity lies in that direction.
I’m in the somewhat marginal Alan Kay camp and think computing can and should be reconsidered from scratch. I cannot prove we are on a dead end, but I have the strong sense that we are and I want to encourage other paradigms and ways of approaching development and computing in general.
I went from VSCode back to vim via Neovim and it works great. I am setup for go and lua. I took a base config called kickstart and removed things I didn't need. Then I added things I do need. As for the community, the channel on Matrix is one of my favorite communities. Whenever I needed help, it came instantly and with precisely what I need. (They must be getting the same things a lot). They never suggested I use a big plugin to solve a little problem as far as I can remember.
All in all it looks like we had a wildly different experience. I suspect the real issue is that I like to work with vim a million times than I did with vscode. You might me biased the other way. I feel better on the command line and it's amazing how much people have figured out already to make things run well and look nice.
This. As someone now in their 30s who didn't learn to code until their 20s, I've tried several times with vim/emacs but it just isn't worth the hassle because I just don't have the free time anymore to endlessly fuck about with config files and learning the ins and outs of each program. So many of the absolute best seem to use one of vim/emacs but then so many of the absolute best started coding when they were children or teenagers with time on their side. It would be a lot easier if they could develop some kind of easy way to switch between these pre made configs but last time I tried chemacs and cheovim I couldn't get them to work as expected. I think emacs has built this feature or something similar into the release coming out soon so I might give it another go in a year or two but I dunno.
hmm.. but you also spent a lot of time to learn programming. Why not invest some time in the use of professional tools?
If you master an editor like vim, you'll never need to spend time to learn additional IDEs. In the past i needed to learn VSCode, Eclipse, IntelliJ, XCode, Visual Studio and some other niche IDEs. All have very different menu structures and keybinds. Just to unify that was worth the time learning vim.
Because I don't need to? I honestly think it would be easier to follow along with a tutorial for whatever language I'm using in any of those editors you've mentioned than one for Vim or Emacs.
This is why I switched to Helix. The configuration is practically non-existent, and it has default configs for all the language servers I could ever want to interact with. I just put the language server binary in my path and I'm ready to go with autocomplete and all the other features.
Helix is cool, but it doesn't have Vim keybinds, which is unfortunate. I find its own system to be a little worse than Vim's (see my other comment about it in this thread).
I've also switched to Helix recently and I get the feeling that is not emphasized enough how much it is about having default integrations for modern standards like LSP, Tree-sitter, and DAP. It's amazing how much functionality you get with just that and not having any plugins or complex configuration.
I actually dread the day Helix eventually gets the WebAssembly plugins system that's been floated around. The current Helix culture of "you get a Kakoune-like editor that can do three categories of "bonus" things, and NOTHING ELSE" encourages a more manageable pace of development (and maybe more importantly: slower updates for those of us exhausted of software churn breaking our stacks constantly), and discourages feature creep/bloat. I love where Helix is at currently. After some tinkering and adjusting a few keybinds, and after a few releases for them to fix various bugs I'd been dealing with, it's quickly become my new favorite editor, and has nearly fully replaced NeoVim. Hats off to Helix.
I couldn't agree more with this! I actively don't want plugins for Helix either - as tempting as it sounds. Nvim is already a create plugin based modal editor with a rich ecosystem, so Helix's no-config philosophy is kinda it's whole selling point.
Some time ago I switched from my bespoke Vim setup to Doom Emacs. I was pleasantly surprised to find out how “VS-esque” it is. As in, it’s very easy to set up it for a new language. Usually I just need to uncomment the correct line in config. And even if it’s not there, finding the correct major-mode and installing it is usually pretty straightforward.
So yeah, highly recommended! Of course, I use the evil mode for Vim keybindings.
Setting up vim with IDE features takes an hour maximum + 2 minutes per additional language.
If that is too much for you, you could have used any of the various vim/nvim distributions with the features already there. You could have even used Doom Emacs with vim keys.
If you don't want to use vim, I do not mind whatsoever, but if you put in a bit of effort the solution to your problems would appear.
Sure, it's one hour if you did that already 20 times and you know the ecosystem.
An hour is barely enough to go through the vimtutor which itself is pretty basic (aka you won't get far with it, so you need to keep learning and practicing).
If you are a vim newbie, it takes a lot of time to figure out you need plugins, then figure out how to install plugins, then what's the difference between plugin installers, finding the needed plugins for your languages, getting familiar with each plugins commands, resolve any conflicts between them, then you need file pickers, debuggers, task launchers, snippets, split screens, multi tabs, etc... Even then, you only made things work once... Good luck figuring that out in one hour...
Then you'll need to keep the config working, practice and memorize the commands, movements, and maybe customize your workflow.
Configuring vim to replace your IDE may be worth it, but "set it up in one hour" is, in my experience, extremely unrealistic.
I think it takes at least one month to get into vim, let alone mastering any of the plugins, and afterwards you keep learning every day.
IMO this is not due to the difficulty of installing plugins (which is becoming easier and easier), but rather to embrace the vim "philosophy".
Many think that VSCode is better because easier to use and has more features. However I think this is because they don't use any advanced features of VSCode either, only the glaring obvious ones.
I am not talking about learning vim. Of course, that is a huge time investment and you have to make your own judgement if that is worth it (for me it absolutely was, but I was in University with few obligations and lots of time).
I am talking purely about going from a vim without IDE-like tooling to one including it. That can be done in an hour.
Still, IMO it can only be done in an hour if you've done it already... You need more time than that for finding the plugin candidates, evaluating them, installing the right plugins, then you need a test run where you lookup the key bindings, on vim it's not as easy to discover features as in a "GUI" IDE.
That's simply not the case because you will, very quickly, run into problems. One example I had with vim recently was that two different plugins both tried to format the same code and actually send each other into some sort of hell loop and crashed vim entirely because they called something in a circular fashion.
That's absolutely representative of the kind of errors vim and neovim configurations have, because it's all independent plugins with very little ability to fix weird interactions. As soon as you have to customize anything in a slightly non-expected way you have no chance to predict if this is gonna break one of the dozen things that are basically held together with duct tape. VsCode or anyting designed to be an actual IDE with its tools better integrated doesn't suffer from this.
You’re absolutely right that this can happen, but wrong that it is representative. Let’s take all the serious vim users in the world. How many have this kind of plugin hell experience? A tiny percentage.
Serious vim users don’t try to create a kitchen sink IDE. They start with a vanilla base and with their way up, including just the features that are important to them.
Starting with something like LazyVim is fine too. Then you get a rich set of plugins that have been configured for you. Lovely! And now just be thoughtful about what you later on top.
Yet half the (neo)vim people in this thread are yelling it's the One True IDE that can, in fact, do everything, and if you are using VSCode or IntelliJ or whatever then you must be a noob or too lazy to invest time in your tools.
"IDEs are easy mode and waste of resources. Its ok to start with them as a noob, but down the line i want to customize every part of my toolchain. (And thats just horrible to do in VSCode etc..)"
I’ve felt similarly, and really wanted to switch to VSCode. But it gives each pane its own set of tabs, while Vim has a single set of “tabs” (buffers) and multiple panes within it.
I’ve been using N/Vim for 25 years, and even after trying for a week or two, I just can’t get comfortable with VSCode’s way of doing it.
I'm in a similar boat. I've used vscode, pycharm/idea, visual studio and vim etc.
I'm currently giving neovim + i3wm a try, and there are certain things I love. Specifically instant switching between my browser and my ide, the ide and terminal.
However, the speed of the LSP(tips, method definitions when coding) is greatly exaggerated. For example for python there is the exact same 10gb ram using behemoth running in the background. Is it faster than using the same language server in vscode or idea? Yes, a bit, but definitely not 10x faster.
Also, I have 2 complaints. One is about keys. There is a huge emphasis in vim world to set your own keys for everything... The problem with that is that for some rarely used action one forgets... Or one moves to a different machine. I think plugin like lsp-zero should more prominently document their _default_ keystrokes. I prefer to learn these before I start setting my own for everything.
Second thing is what makes an ide most useful. A tree view file manager. I'm currently using nvim-tree. It's a nice plugin, and it works, but it lacks certain features like displaying large trees of empty folders in a "collapsed" way like vscode does.
So, for now I'm sticking with nvim, but I can't say for how long..
You might be interested in installing the fzf-vim plugin [0]. It has a user-defined command :Maps which can be used to search through all keybindings (you can also do this with just :nmap in vim, but the fzf interface is much nicer). It also provides :Commands. This behaves remarkably like VSCode's command palette.
I don't disagree, it's always a balance of "how much time do I actually want to spend on my workflow vs getting the work done", but I think the only reasonable way to use Vim is to build your environment over time (many years) and have it in source control so that you never have to do it again. You'll still have to keep making updates of course, but that's typically a bit smaller time commitment.
this is basically why I moved to https://github.com/helix-editor/helix/ for most things. neovim setup is a nightmare these days. 0.5 introducing Lua was both great (yay! vimscript sucks!) and horrible (oh no, everyone took this power and made a full operating system worth of complex stuff out of it that rarely fits together cohesively, and it all updates so frequently now that I can't keep up)
I don't actually think it's Lua's fault. And I don't necessarily want to jump and say "the improved accessibility of this thing turned it into an unusable circus", because that's both unnecessarily sassy and also likely prescribing blame in some places it doesn't fully belong. But there's something that tidally changed in that time, and especially in the past 2-3 years, my vim setup became a thing I dreaded updating (because it would 100% guaranteed, every time, break something about my workflow)
> I've been using vim for years, switched to neovim, and at this point I'm ready to throw in the towel and just use vscode for anything beyond simple text editing.
I’ve done that a couple years ago after ~15 years of happy vimming. Still yearning for the text manipulation language combined with macros, but all the other gains significantly outweigh the worse editing capabilities.
There's an extension for almost everything, right there in the UI.
The fact that it's electron means there is native support for graphical preview in e.g. markdown, mermaid, plantuml, jupyter, etc.
Relatively sane defaults. I haven't tweaked much of the editor except the color scheme and shell startup timeout.
Zero messing around with language server setup. It's 'install extension' and go. Sometimes a window reload is required, but it restores the session intact, even with terminal history.
Remote ssh (and WSL on windows) is super seamless. The way I've used vim was always ssh+tmux. Most of this is unnecessary with remote ssh in vscode.
There's probably more but these are what comes to mind immediately.
I wonder why people are asking Google search like they would ask a person?
Just googling "black nvim" yields a correct result (project repository) where you can follow the lines to get it installed/configured in a minute.
Why would someone ask "How do I set up Black with neovim to format my Python files on save?", hit the reddit/quora/another obscure forum where he finds some hostile people who doesn't well explain to him how to set up black with neovim to format for his python files on save. DAMN. Just type in "black nvim", hit return and head to repository boy. There are genuine docs and installation instructions from the author, you don't need other people to explain it to you.
Google is a search engine not an answer engine, so if you're looking for struggles instead of information you'll find it by inputting questions instead of indexes.
I'd recommend trying a neovim distro like lunarvim out. It has black and all other typical ide features configured out of the box and doesn't mess with your normal neovim config.
I tried out spacevim, but then some feature was getting in my way and I couldn't figure out how to turn it off (I've forgotten what now).
I think thats a disadvantage to some of these heavily customized vim flavors. Plugins don't necessarily work out of the box, and when they do they promote their own way of interaction that sometimes needs to be learned.
As a recent LunarVim user, I can really recommend it.
Coming from vanilla vim, it has been a pleasure to use. More power at the cost of less configuration. And beginner friendly (for someone that's familiar with vim)
Did you try LazyVim or any other neovim distro? Seems like you're complaining about configuring neovim from scratch, which is that pain that neovim distros aim to remove
Yes I did. And they work fine, until you need to do that one thing (e.g. "Set up Black to format on save"). Now you are back in that world of pain of figuring out which plugin needs to be installed/configured, only now you are figuring out someone else's way of doing it.
LazyVim gives you Mason to install Black. You could use :MasonInstall black and restart Nvim to ensure black is loaded.
Or if you want to have it automatically available on other setups, black is a builtin formatter in Null-LS, so you would just have to add "black" to your builtin list for your Null-LS configuration.
Format on save is already set up.
I've not used LazyVim. It took me 30seconds to look at the docs to see what was available. Yes, getting to the point where you have Mason, NullLS and LspConfig and the glue-plugins to make them work well together takes more than 30-seconds to set up, but once it is adding a new LSP or formatter takes no time at all.
I think you're going about the wrong way if you're reaching to plugin for every simple thing in vim. Granted, I will say that vim has steep learning curve, it kinda gives you the power to do your _own_ way which is probably why you're seeing people do their own way.
Also, you sort-of have to shift your mindset to embrace unix/shell as your IDE. But definitely reach out to other tools if it's not your cup of tea. Like many others have said, if you're trying to force it into something it's not then you're going to have a miserable time.
As for your e.g. it would be a simple autocommand to run black that's installed in your machine on buffer write event in your neo/vimscript.
An alternative to Neovim or VScode that might be worth checking out is Helix (https://helix-editor.com/). It is a Vim/Kakoune inspired editor that is really starting to hit its stride. I haven't used it extensively yet, but I'm testing using it for development now and am thinking of switching to it full time. It maintains the minimalism of (Neo)Vim while coming with a great builtin setup like VScode.
Helix is interesting but I don't really gel with its editing language (subject + verb instead of verb + subject like (n)vim's). Happy to discuss what I think is lacking in more detail, but basically: the premise of 'you can see what you're about to operate on before you do the action' is satisfied for me by visual mode, and I like macros better than multiple cursors. So I don't want a (subjectively) less efficient editing language for these features. I think I generally agree with the complaints in [1], with the addition that I don't want to have to chord (press shift in the case of Kakoune, I forget what helix does here) to extend a selection.
I've seen that breakdown before and have skimmed it but didn't really find an analytical breakdown of why style X is better/worse than style Y for person Z very useful. Tools preferences are to personal and varying. It really depends on how it meshes with your style and the only way to really test that is to try it out.
Helix is quite nice, with some sensible defaults and an easier setup. The keybindings take a bit of getting used to if you are coming from it with years of vim muscle memory, but kind of make more sense when you think about it (select+action vs action+select). It's still rough around the edges but one to keep an eye on.
> In the meantime, I can just Ctrl+P and install what I need in vscode and be on my way in a few minutes.
Vim's built-in package management means all my plugins are stored as git submodules that are installed alongside my configs. I don't have to remember what extensions I have and Ctrl + P and install them one at a time.
VSCode's settings.json and extension-level configuration is also extremely cumbersome. You're paying a time tax no matter what tools you're using if you want to customize them to fit your workflow. Personally I'd rather pay that tax 1 time with Vim and then carry the same setup with me to any PC than have to eat that cost every time I need to configure VSCode on a new machine.
I also went through this phase about a year ago, then just gave up and went with VSCode for its superior out of the box experience. That said, I still fire up vim to read files in a server or make one line config changes, but everything else....VSCode.
Related: Imagine having to remember the full scp / rsync command to sync source file(s) between your local machine and server, but it's just a drag and drop on VSCode.
I've just come around to accept that we've been blessed with great hardware over the years, and it's a waste if those extra CPU / GPU cycles aren't translated to significant dev productivity improvements. I'd take slower (~ ms) editor paint times over saving hours messing with vim configurations.
> Related: Imagine having to remember the full scp / rsync command to sync source file(s) between your local machine and server, but it's just a drag and drop on VSCode.
What's hard about this?
rsync -a dir/ server:dir/
I'd much rather have commands in my terminal where I can search for them later than do things visually and have no record of what I did once and how to repeat it.
Strange, the only thing I need to do to get everything I need these days for a new language is install the right LSP provider and point vim to it. It used to be much harder, now it's closer to trivial.
I just want a decent open source native editor with a native GUI.
10+ years ago, when I and almost everyone I knew were on Windows or Linux, this was simple and ubiquitous. UltraEdit, Notepad++, Vim and Emacs of course, etc, there were dozens of options to choose from.
Then I and most developers that I know switched to Macs, and now this is an alien concept. There's a dearth of open source Mac development, and much of what exists uses Electron or some other crutch to avoid committing to the Mac platform.
I've tried Neovim, but the "GUI" version is basically just the console version in a window. Might as well just skip it and do everything from the terminal.
There is MacVim, but you have to open it from the command-line in order for it to scan your home directory properly. If you pin it to your dock and launch from there, then it doesn't know who you are and launches in stock vanilla mode without reading your .vimrc. Same problem with Geany. I could PROBABLY figure out how to modify the dock icon to launch with the right flags, but the point is that this is unreasonably complex and arcane for most users.
So... I just stumble along with VS Code by default, like most people these days. It's an odd shame that cross-platform desktop app development is as dead as it is, especially considering that most devs today are not using the dominant platform anymore.
> I don't particularly like vscode. It's heavy and slow and janky, particularly on older laptops. I don't like being sucked back into the Microsoft ecosystem after spending years getting away from it. But ultimately, I want to just get on with my job, and my job is not Lua Developer or Neovim Plugin Expert.
I've personally been test driving JetBrains Fleet and have to say that it's pretty okay for most of my lightweight dev needs: https://www.jetbrains.com/fleet/
It's still a bit early for it and it doesn't have the same ecosystem that VSC has, but it'll probably be even better in 1-5 years and is decent already.
For most of the more heavy work I just use JetBrains IDEs, but that's very clearly a no go for the less capable devices like my netbook.
For even lighter options, on Windows there is Notepad++, which has been okay although not an IDE.
I don't need an IDE for Python. Of course I can use a plain text editor if I want. Hell, nano even.
But right now, today, at work, I have a large legacy Django project to maintain, and it's kind of nice having little things like auto code formatting and linting to help me as I go and prevent me from making dumb mistakes and saving me a ton of time so I can focus on the problem at hand, not making the code look nice for review and I can hop between buffers to fix up the tests as I change the code.
I can certainly just run black/isort/ruff what have you manually, or with pre-commit, sure. But it's more productive to be able to see changes as I work.
Sure maybe I shouldn't be using Python, and maybe the original developers should have written it in Rust or whatever. Fine. But that's not what I'm being paid for.
Sadly I completely agree with you. Whats even sadder is I recently made a post proselytizing the virtues of neovim over vscode.
The final straw for me was discovering that vscode automatically updates packages and imports when moving files around a java project - something that doesn't seem possible in neovim despite hours of research and lua tinkering.
Edit: I did use Helix for awhile (long enough to still have muscle memory for their editing model) but it’s just not there yet and eventually moved on to Zed.
I love the concept and engineering behind Zed, but considering how software startups tend to fare, there's just no way I'm going to mentally invest in a closed source dev environment.
Even if they succeed commercially, chances are some day Microsoft just buys the whole thing and shuts development down a week later. No thanks.
The way I see it if Zed fails I just go back to VSCode and I’m no worse off than before. The nice thing about Zed is that it’s batteries included so it really isn’t hard at all to pick up. I did in maybe 15 minutes tops, seriously.
I am using mostly default settings on my neovim setup for most plugins.
I can't do much with vscode before also install tons of plugins and eventually setting them up. The only major difference to me is a central marketplace for vscode plugins instead of relying on github search engine+recommendations and being subject to telemetry I don't want.
I think it's important to know a terminal text editor if your work involves remote servers. Then once you know one of the good text editor, you may be tempted to use it for other tasks. That's where people get into trouble.
The base emacs and vim documentations are actually excellent, the problem is the plugins. Just use an IDE for IDE tasks and a text editor for text editing tasks! I'm not going to start a new project in Intellij just to edit a config file or take notes about something. Why would I want to pollute my minimal emacs config so that I get a flaky IDE?
(Of course it's fun to program in a text editor because it's fast and distraction-free, which is why I use them for hobby projects. But for professional work I use professional tools.)
Agree. It's crazy and I've given up. I have windows and linux computers, and what works for one, doesn't for the other. Setting up a shared vimrc is a nightmare. In the end, I only use vim for text. Colab and jupyter for all the programming.
Because files and directories make up the core organization and architecture of any project.
Obviously when I'm working with 1-5 files then Neovim is great, but it's awful when I'm working on a real project with dozens of directories and hundreds of files. I can't hold that much contextual information in my head to simply remember the correct file name (or function name) and hit some keyboard shortcuts to jump to it. I need to actually see it all together.
VS Code's project tree and tabs system works great for me to always understand where I am working, and I don't have to remember any keyboard shortcuts to navigate.
My experience with vim differs drastically and I believe the root of most problems you had stems from trying to turn vim into an IDE.
I won't argue at all. If you prefer IDEs, you go for it. But maybe vim and neovim aren't the best choices.
I use vim as a text editing tool, solely. My .vimrc contains ~ 20 lines. Use 2 popular plugins to help me finding and opening files, and one plugin to support editorconfigs (useful for sharing formatting rules with folks using vscode in the team). And I use makefiles or other scripts to call external tools (formatters, linters etc).
There's probably a billion of plugins which could increment my productivity, but honestly I don't care much.
Just tried today to switch from Vim to Neovim as my EDITOR when I work over SSH (I use VS Code otherwise, I know about its SSH capabilities but don’t use them to edit just one file).
Result: had to add a PPA on my Ubuntu server (not ideal but OK), most plugins require nvim 0.8+. Switched to the unstable PPA (because the stable PPA ships 0.7), turns out it doesn’t ship the latest release but instead a nightly dev build.
While editing Lua configs of Neovim, I tried to use ‘micro’ just for fun.
Result: my new EDITOR and GIT_EDITOR (that I previously set for +startinsert) are now set to ‘micro’. Alt+/ for commenting code, sane shortcuts, and code highlighting cover 90% of my needs.
(As much as I'm team *Vim) Vimscript is a mess. Oh, so you mean 'noremap' means remap this? No way! /s
The story about plugins is so true, regardless of the above. People will want you to install a plugin with 5 stars that will not play nice with anything else to do something basic like pre-save processing. Or one of the 'everything but the kitchen sink' plugins that has an end goal of giving you a Borgified Vim
And in the end I sincerely don't care, I could use the time I'm playing with this to install VSCode, or something else and have something more complete OotB
I use vim for years, too but also I keep my .vimrc and, more recently, .vim in a git repo (using bare repos for dot files discussed here: https://www.atlassian.com/git/tutorials/dotfiles). So, getting a functional environment on a new system is close to running `git pull` once.
I don’t update plugins too often, because they work, but I also don’t use too many. Based on my git history, I last updated a vim plug-in 11 months ago.
I've stopped using vim and started using visualstudio + vim plugin and called it a day. for me, it's just not worth it to tinker with truckload of plugins just to get ide features work.
I think learning vim was very worthwhile for me cause I now use vim bindings if it's supported, but yeah vscode was getting slower for me the past few months and I decided to try neovim again and man so many things have changed since the last time I tried it with the new Lua config. I feel like it'll take me a day to recreate a config im satisfied with and it'll probably have a few bugs too after using it for a while.
Vim definitely was designed and remains an editor first and foremost. The IDE=like functionalities were clearly cobbled together later and it shows, on that we agree.
What always surprises me however is why having realised the limit of this model, decide to go back to VSCode, another editor with cobbled together IDE=like functionalities? IDEs are nice. Last time I checked VSCode debugging was still subpar and required fiddling with configurations.
I use VSCode with one of the neovim extensions for 'IDE tasks' (none of those extensions is perfect though, but they're "good enough"), and a vanilla vim without customization for quick text editing tasks on the terminal (sometimes even within the VSCode terminal panel).
E.g. for me, "vim" is more like an input scheme that works across editors, less a particular product.
I was going to ask a similar question. This seems really cool, but since I already suffer with the complexity of vscode at work (but it's supported so is a net win), and I have my Vim setup that is small enough to (mostly) understand myself, why add a third thing which combines bad features of both? I'm responsible when it breaks, and it's complex.
For me vim is a good text editor. You could somehow turn it into an IDE — even into a good one, but that is not what is the core value proposition of vim.
I am mostly using sublime text for programming projects and vim for editing configs on headless servers. If I like to use vim for programming I'd try to add vim keybindings to my IDE instead of adding an IDE to vim.
Same sentiment here. After 2 decades of development and having been through phases such as Gentoo, Vim+plugins, and other deep dive hobbies, I enjoyed the time spent, but now I just want something that works out of the box. I've found IntelliJ/GoLand with Vim bindings to work well for me. That Vim muscle memory is something I'll never get over.
Code should be self-documented.
And editor should have a good mechanism to help you understand the source code.
Emacs does better in this angle than Vim by far.
You can find the documentation for every variable (describe-variable) and functions (describe-function) easily and jump to their source codes.
> The amount of work needed to get a basic IDE up and running for your languages of choice, even for commonly used languages such as Python or Javascript, is far too much for someone who wants to get on with their day job or hobby coding and doesn't want to spend precious hours fixing obscure issues in Lua.
First off, editing Python (I am not familiar with Javascript enough to make any claims about it) doesn't require any sophisticated IDE and can be done quite proficiently in any decent text editor. I don't say this having written 3 lines of Python in my life, I say this with about 9 years of experience writing at least some python almost every single day. I think the powerful baseline that an editor such as vim or neovim provides is sufficient for most development tasks in most languages which aren't e.g. Java. That being said, integration of a syntax and type checker can be nice to make development a little bit more painless and tab completion can sometimes take something which might take 20 seconds to look up and verify and turn it into a 3 second task.
Genuinely the initial up-front work for these features for a new language for me is to make sure a language server is installed in the path and add it to the list of active LSPs in my configuration file (one line change).
This takes about a minute or two depending on how quickly your package manager can install the language server. Sometimes it's some obscure language where the language server isn't easy to find. There's a plugin for automating the installation and configuration of language servers. There are pros and cons to this plugin.
> Furthermore, the community does not have a good culture of documentation and learning: too many plugins have very sparse docs
This is still true about the lua API for neovim, that being said, once you learn it once, it stays mostly stable (and when stability breaks, it's mentioned publicly in the changelog) and leaves a lot of power at your fingertips. When it comes to third party plugins, a lot of them are just snippets of code which someone wrote and found useful, I think expecting a book on that is a bit excessive, a lot of the time you can just read the code or write your own more tailored version.
> other online resources such as the Neovim subreddit are hostile to newcomers with "RTFM" a common answer
My personal experience is with the neovim IRC channel which has generally been helpful. Although, again, if you learn the APIs which neovim exposes, a lot of questions can be answered by simply solving the programming problem which presents itself. I rarely find myself reaching for a support forum.
> The community is also fragmented, with too many ways to do the same thing in the name of some platonic ideal of personal freedom over practicality.
There's a difference between the editor having many ways to do the same thing and the community having written many solutions for the same problem. I would struggle to find a community of programmers who don't have the latter problem, but neovim doesn't really have the former problem to any major extent.
> A simple question like "How do I set up Black with neovim to format my Python files on save?"
... is a programming question. What events does neovim expose hookpoints for to do things such as auto-formatting? There are many events but BufWritePre seems the most appropriate. How do you call black from neovim? Well the PSF official neovim plugin is probably a good starting point. How do you glue this together? Well, the on_attach function of the LSP for python seems like a good starting point.
Now how you integrate this into your config is again a little programming problem in and of itself. But it's not really a complex programming problem. You are after all not trying to write some large complex and scalable system. You probably have all the tools necessary to organize your code well. I went with a highly functional approach which passes functions around everywhere but you may be more familiar or happy with another approach. The beauty of a neovim configuration is that you are the only person who needs to maintain it.
I don't find any of this particularly time consuming. I normally don't touch my neovim configuration for months at a time as it continues working. I keep it tracked in a git repository and synchronise this across machines whenever I change something. My only personal annoyances with neovim are the fact that they haven't stabilized it yet and that package managers for neovim aren't as mature as e.g. something like cargo where you can use a lockfile. That being said. It's a powerful tool which requires a time investment to learn. But if you learn it, you can achieve really quite sophisticated things without needing to spend time looking for a very specific pre-existing solution. Usually to solve your problem you will need only a small handful of lines of lua.
> In the meantime, I can just Ctrl+P and install what I need in vscode and be on my way in a few minutes.
That's nice, but what if you want to run a different auto-formatter depending on the codebase? What if you want to automate this? What if you want to disable auto-formatting altogether in some cases? What if you want a configurable list of auto-formatters per codebase? With neovim I have this particular highly flexible feature working in ~20 lines of lua. How much would it take to modify or make a vscode plugin to implement these features?
My most common issues with vscode were: lack of flexibility, lack of customizability, and lack of transparency. But these are expected tradeoffs of such a system. I understand why vscode exists with these tradeoffs but I am not willing to make them.
I agree that neovim is not for people who are not interested in learning their tools. For people who want to just start typing code with whatever automations they are reasonably familiar with, and willing to accommodate any weird variations in the workflow which using a different tool might entail then vscode seems like a fine choice. But the main problem with neovim here is your own perspective of it. It is first and foremost a powerful text editor with an IDE building toolkit. It is not an IDE itself. You can use it to very quickly design a bespoke IDE which you like, without writing very much code. But you need to spend the time to learn its APIs first. If spending the time needed to learn it and then writing ~20 lines at a time to get it working how you want is not your cup of tea, then don't use neovim, it's clearly not for you.
> I agree that neovim is not for people who are not interested in learning their tools.
That, right there, is one of the biggest turnoffs I have encountered from the community. The sheer disdain in that sentence alone.
I learn many tools, and am deeply interested in learning them. That includes languages, frameworks, databases, infrastructure tools, operating systems, standards and protocols. I wouldn't be in this job otherwise.
However, my time is limited. I have to be selective in what I spend time learning. Much of that choice is determined by my employer, project and other requirements. Free time left over for learning other things is even more limited.
Learning another language and API and plugin ecosystem just so I can configure my editor? Maybe for some people, that's time well spent, but personally - having spent a fair bit of time with neovim to give it a fair shake - I realized that what I don't need is a perfect artisinal text editor, but a good-enough IDE that lets me do the things I'm either actually interested in, or paid to do.
Vim as a simple text editor? Perfect, use it every day when dropping into a headless server to edit a config file or two. For an IDE? I don't love vscode, but for what I need, it's fine.
I'm sorry that you read it this way, I think I could have written it differently. That being said, I don't agree that any of the things you listed are tools.
Moreover, reading what you wrote in your original comment from a more negative stance, I also think it's easy to read it as disdainful but I chose not to read it that way. I would appreciate it if you were more positive in your reading of what I write.
Tools in my mind are things like: a keyboard, your IDE/editor, your build system, your VCS, your userspace utilities (sed, awk, cat, ls, grep, etc), code formatters, code linters. I guess "tool" is probably not the best name for these categories given that I can understand why you would also call a library a tool but to bring in an analogy from woodworking, tools are things you use to make things from the materials (what would be libraries, frameworks, programming languages, etc).
So having this distinction in mind, I don't think it's necessarily incorrect to state that you are of the opinion that what I would categorise as "tools" are not worth learning and (I should add) modifying.
Again, I would like to stress, I am not trying to make any objective claims as to how correct your approach is. I am simply observing that there seem to be broadly two categories of programmers. Those who feel like investing time in learning and writing/modifying "tooling" is worthwhile and those who do not. I feel like you fall into the latter category.
In this sense, I don't think vim, neovim, or emacs are really appropriate for people who don't feel like time spent learning and writing or modifying (let's call them) peripheral tools is worthwhile. Whereas you feel constrained by the need to understand what to you might feel are "irrelevant details" (the need to know the API) about neovim, I feel constrained by what you might feel are "irrelevant details" (the need to adjust to a specific workflow which I might not be used to, the need to constrain myself to a specific set of plugins) about VScode.
That being said, I will say again, to claim that vim takes a lot of time to use and configure is simply wrong. But if you feel like having to learn an API to use an editor is a waste of time then it would explain why your experience might be like this. It's not possible to use vim quickly without having learned the API. Likewise, I feel like having to adjust to a specific way of editing as envisioned by a specific company and a specific plugin writer is a waste of my time and it would explain why my experience of VScode is that it takes a lot of time to configure and use whereas your experience is different. This doesn't mean that VScode takes a lot of time to use and configure, just that it's fundamentally not for me.
I hope the above clarifies things. I would be happy to agree on a different term than "tool" or a clearer way to distinguish between e.g. an IDE and a library or framework.
> Again, I would like to stress, I am not trying to make any objective claims as to how correct your approach is. I am simply observing that there seem to be broadly two categories of programmers. Those who feel like investing time in learning and writing/modifying "tooling" is worthwhile and those who do not. I feel like you fall into the latter category.
I use zsh, with customizations. I know git, and mercurial, and a few other VCS I've forgotten. I know my way around the Linux toolkit. I can configure a Python or frontend or Go environment with whatever linters and formatters and pre-commit and so on and so on. I have a fat repo of dotfiles. Hell, I use vim whenever I need to work on headless servers or the odd config file and the like. Works fine, in that use case.
Every time I learn or modify a tool, I look at whether there is a net benefit in learning it, whether it makes me more productive. Zsh shortcuts for example are tiny, but I get a nice little productivity boost that adds up to many hours over time.
I have spent the hours learning and configuring neovim, but run up against that point where that time spent is no longer yielding that benefit, compared to just using vscode and putting up with its issues.
So, I chose one tool over another. But it's a generalization to say I somehow don't think learning "tooling" is worthwhile.
Okay, so it seems you certainly fall into the category of people who generally find it worthwhile to learn and configure/modify tools. So I really don't understand how you came to the conclusion that neovim and vim are not worth the time.
Neovim takes a lot less time (weeks to months) to learn than something like git (months to years), while I know both very well, I find that I am more often interacting with my text editor than I am with git.
It seems to me that the tradeoff of using something like VSCode, unless it perfectly matches your particular workflow, is much more friction than dealing with git vs something else.
To that end, if you have given neovim a chance and learned it, then I struggle to see how you had problems with something like e.g. making :Black run automatically before the file is written.
Autocommands are a fundamental vim feature, one of the most important for vim related automation aside from rebinding. Something you will have encountered as soon as you search for "vim how to do X when Y." Figuring out that the PSF black vim plugin is a good option for a way to run black from inside vim is a matter of a 10 second google search. I can understand this being a potentially difficult problem if you really had no neovim configuration experience, but if you have learned neovim then this really is a single line addition to your on_attach which you would have already had to configure for the python language server of your choice.
And even then, the black documentation page explicitly shows how to use vimscript (which can be embedded in nvim lua syntax using vim.cmd, again, a basic neovim feature you would have encountered in any guide to configuring neovim) to achieve this in 4 lines.
I use neovim because it eliminates friction. Whenever I do something and find myself repeating an editing or reading adjacent task and making mistakes I think to myself: "how can I solve this once and for all?" I sit down, fix it in neovim and lua in 20-40 minutes. How do I justify the time investment? The 40 minutes (or hell, even if it took 2 hours it would still be worth it) investment once every couple of months to improve some aspect of my workflow keeps the friction down and the reduced friction more than makes up for the 40 minutes or 2 hours of lost time because I would lose much more time on frustration and lack of motivation.
This friction doesn't affect everyone as much as it does me, which is why I notice other people, less affected than me, don't find dealing with learning and configuring/modifying/writing tooling to be worthwhile. But again, what you wrote indicates to me that this kind of friction _does_ matter to you.
So my question is, how do you justify the friction of VSCode (as you yourself put it, VSCode isn't perfect) when you have tools such as vim, neovim, emacs, or whatever else that are designed to help reduce friction for a modest but steep initial learning curve.
> how do you justify the friction of VSCode (as you yourself put it, VSCode isn't perfect) when you have tools such as vim, neovim, emacs, or whatever else that are designed to help reduce friction for a modest but steep initial learning curve.
Because VSCode also is designed to reduce friction for a modest but (less) steep initial learning curve.
I have used vim a lot. I've also used VSCode a lot. It sounds like you haven't dived into VSCode in the same way you've dived into Vim. I'm trusting you that your Vim setup, after tweaking it to your liking and diving into it, is perfect for you. So I'm asking you to trust me (and the other commenter), and my VSCode setup, after tweaking it and diving into it, is perfect for me.
Using Vim emulation in VSCode, plus the richness of VSCode configurability, I have an environment I'm over the moon about, and it was less steep of a learning curve than Vim.
You seem to think that anything that isn't Vim or Emacs can not compare. I'm asking you to reconsider that.
>You seem to think that anything that isn't Vim or Emacs can not compare. I'm asking you to reconsider that.
I don't think you have read the discussion between me and the other commenter very thoroughly if you came to this conclusion.
I have repeatedly re-iterated my stance so I would rather not do it again but tools such as VS code are inherently inflexible (I have put a couple of weeks into trialling and configuring vscode) for good reasons and to tailor to a specific audience.
My argument is that for the other audience, tools such as Vim or Emacs (or in some extremes, writing your own editor or using something even more obscure) offer superior flexibility and offer the possibility of much reduced friction in exchange for more time needed to learn, configure and maitain and that this setup is worth it for that different target audience which the person I was talking to has indicated membership in.
For a more in depth overview of my stance, please don't skim read what I wrote and as a result jump to incorrect conclusions.
JetBrains have excellent offerings for both JavaScript and Python, in my opinion. I happen to like Neovim and I don't use the languages you have issues with the Neovim side of, but if I were to use an alternative it would definitely be JetBrains IDEs.
They are certainly still trying. I used vscode a while ago. Some of the best and most essential extensions like LiveShare and Remote are proprietary and worked only on the proprietary build of vscode (the last time I checked) and wouldn't work on OSS builds like vscodium (why though?). Both these extensions and the proprietary build of vscode come with telemetry that's either opt-out or always enabled. They nudge you ever so slightly and gradually towards the proprietary build. I left vscode since I don't like such manipulations.
It's not lock-in, it's feature differentiation. Other platforms are free to develop their alternatives of these plugins. There's nothing preventing the community to develop a fully OSS Liveshare or Remote extension (and they are!)
but there is.
VSCode core may be open source, but the plugin marketplace certainly isn't.
So if you for example use VSCodium, you don't have access to the plugin marketplace and eather have to use an alternative or manage your plugins completely manually on the filesystem.
So what? You use the plugins available on the platform you use, that's standard practice. Would you complain Sublime Text plugins are not available on VSCode? Or emacs plugins are not available on vim?
This is not lock-in, just a different feature set.
neovim extension + vscode is a great pairing. full neovim in normal and visual mode but you can call out to vscode anytime you want in those modes and you also get neovim extensions too. it's great and fast... worth a try.
I've never tried neovim, but have been a vim user for over a decade and never really dealt with problems where I need to touch vimscript at all. Is neovim that clunky? Is it plugins?
My feeling is that neovim per se, as a piece of software, is fine, but that it belongs to one of those developer communities that prizes freedom and infinite configurability over the day-to-day practicality of getting things done. So something like LSP integration has too many ways to do it across too many plugins.
If you are deeply involved in the community and are willing to put in the time, sure, you could probably build something superior to vscode. But the time invested to get there might not be worth the marginal productivity gains.
> But the time invested to get there might not be worth the marginal productivity gains.
Most of the time invested has been invested by other people. My own nvim setup is just a curated list of other people suggestions. I haven't put a lot of research into it and I still find it easier/superior to use than some other editor/ide like vscode.
No, it's not clunky. The plugin community is just a lot more active, imo. I personally avoid plugins wherever I can, since I prefer to write my own little Lua scripts that do stuff the way I like. (And I quite like the Lua API-- the lua plugins I use seem be a lot faster/less janky than the vimscript ones, as well? not sure)
Vim, the program, I find useful in limited cases. Vim, the keybindings, I find I try to use everywhere -- from the browser to every IDE I ever work in.
Yes I did, and no it didn't really help. Sure it was a much slicker starting point, but when I needed to do a bit more (ie. configure a formatter) it just added more obfuscation than anything. The "pre-cooked" part does help with setting up linting, but formatting...you're kind of on your own (if you search the source you can find an example with prettier but you will still need to add your own integration for anything else).
The amount of work needed to get a basic IDE up and running for your languages of choice, even for commonly used languages such as Python or Javascript, is far too much for someone who wants to get on with their day job or hobby coding and doesn't want to spend precious hours fixing obscure issues in Lua.
Furthermore, the community does not have a good culture of documentation and learning: too many plugins have very sparse docs, and other online resources such as the Neovim subreddit are hostile to newcomers with "RTFM" a common answer. The community is also fragmented, with too many ways to do the same thing in the name of some platonic ideal of personal freedom over practicality.
A simple question like "How do I set up Black with neovim to format my Python files on save?" will yield a dozen answers, each one with someone's favourite plugin. Setting up that plugin will require another plugin, and so on until you end up with a Jenga tower of dependencies that doesn't quite work the way you want, but is too fragile and time-consuming to tweak correctly.
In the meantime, I can just Ctrl+P and install what I need in vscode and be on my way in a few minutes.
I don't particularly like vscode. It's heavy and slow and janky, particularly on older laptops. I don't like being sucked back into the Microsoft ecosystem after spending years getting away from it. But ultimately, I want to just get on with my job, and my job is not Lua Developer or Neovim Plugin Expert.