"I don't want to learn all that Vim stuff and configure it myself so I will let someone configure it for me and learn their stuff instead."
Something like SpaceVim kind of makes it so someone doesn't have to concern themselves with that because someone designed the entire thing from the ground up so you're less likely to run into issues that someone who's gradually built up their vim config over time would. That isn't even mentioning the fact that it all hypothetically just works together and you can be productive actually programming out of the box with something like this.
I think for someone that is interested in using Vim (or Emacs, for that matter), these premade configurations with their own superset of paradigms seems like a much better approach to going about it. They can, after all, switch to building out their own config down the line if they feel the need or desire to.
The argument that they can still decide to do it properly when they want is not grounded in reality. People get used easily to those things so two things happen in those cases:
- they get very frustrated by the real Vim, - they try to replicate their previous ready-made config anyway.
It's all just some elaborate avoidance strategy.
This is not really the universal truth that you think it is. I remember when I learned to drive my father started me on his car with a manual transmission. I skipped gears, Started from a stop in 3rd gear, and had a whole lot of frustration trying to deal with both the concepts of driving the car, the rules of the road, and trying not to completely destroy the clutch of the car. I switched to learning on my mother's car, which was an automatic. I gained confidence on the road and then I went back to learning how to drive stick. This resulted in a much easier time for both me and the clutch. So no, I wasn't better off learning it directly. The same can be said for something like walking and then running, or learning how to program. They typically don't start students off learning to write Assembly even if their intent is to be an Assembly programmer. Training wheels on a bike exist for the same reason too. Can people make this approach work? Sure, but that doesn't mean it's better. In fact I think in quite a lot of cases it's way worse.
> they get very frustrated by the real Vim
They are using the "real" Vim. You being weirdly gatekeepy about this doesn't change the fact that they're using the same application that you are, except they loaded a config different from yours. There is a list of different keybinds from vanilla vim in their documentation and you can disable them with one line in your config. Pretty much all the typical vim paradigms are exactly the same.
> they try to replicate their previous ready-made config anyway.
kind of their prerogative and one of the nice things about extensible programs like vim is that people can do exactly that. I could change vim to use CUA commands, be mouse-focused, and default to insert mode and I'd still be using vim.
All of those examples are about prerequisites, though. You learned to use manual transmission in a car with a manual transmission, not in a car with an automatic transmission. You learned to drive a car in a car, not on the back of a horse. The person who learned Assembly learned it by doing Assembly. Etc.
> They are using the "real" Vim.
They are shielding themselves from "real" Vim.
> You being weirdly gatekeepy about this doesn't change the fact that they're using the same application that you are, except they loaded a config different from yours.
The config they use not only hides Vim behind dozens of plugins but also adds a few new concepts to the mix that they are forced to learn _on top_ of Vim's ones. What a waste.
> kind of their prerogative
Kind of mine to suggest a different path.
> They are shielding themselves from "real" Vim.
Define "real" vim.
> The config they use not only hides Vim behind dozens of plugins but also adds a few new concepts to the mix that they are forced to learn _on top_ of Vim's ones. What a waste.
It doesn't hide Vim behind anything. Extensibility is baked into Vim and a great deal of effort has been put into ensuring that it can be extended to suit people's needs. One of the largest changes in Vim 9 was working on increasing the capabilities and speed of Vim9 script. Whether someone writes their own config, doesn't use one, or uses a premade configuration like SpaceVim, they're still using Vim.
They trade time learning SpaceVim's paradigms in exchange for not having to configure vim themselves which means they can spend more time learning how to use Vim for getting work done rather than faffing about with plugins and designing their own keybinding schemes. If SpaceVim completely eschewed Vim paradigms for its own you might have a point but that's not the case. It very much adheres largely to how Vim itself works while making it easier for someone to get up and programming.
You could pin your extensions in packers. Not sure about other plugins managers though.
- I work (or rather workED until a month ago) on LSP implementation for C++ (clangd) and I frequently need updates in the client - The client (Neovim LSP client) is being developed quite rapidly
For the reasons above, I did update the LSP plugins and Neovim versions quite a lot. And (in my experience) that is the thing that breaks the most over the past 2-3 years. Everything else is kind of OK, but it doesn't make much sense without the LSP. I could update only some plugins and keep the others at a fixed version, but then overall I'm not getting bug fixes & features which makes me kind of sad (that's why I started building my ultimate (Neo)vim setup in the first place).
I guess I should really stick to just a couple of basic plugins and throw everything else out.
What’s the difference between someone who uses vanilla, unconfigured Vim and someone who uses unconfigured SpaceVim? Merely that one of them likes vanilla Vim and the other one likes SpaceVim. What’s the problem with not configuring things if you don’t want or have to?
Also the mock quotation thing is way overdone around these parts, jeez.
It is used by and marketed to both populations.
> What’s the difference between someone who uses vanilla, unconfigured Vim and someone who uses unconfigured SpaceVim?
As if those were the only possibilities.
> What’s the problem with not configuring things if you don’t want or have to?
No problem and no idea where that comes from.
I found this was a good compromise because I jump around all sorts of systems and broken ass container hosts so any vi variant is home then.
If you keep your dotfiles (vimrc included) in a public repo, checking them out to every new system may become a useful habit. Or you can even do curl ...| bash to setup your work environment every time.
Pulling stuff out of GitHub regardless of the repo into a production machine should be frowned upon anyway.
It's not efficient for many different developers to each learn how to configure Vim to the point where they can get an effective editor out of it. - For this, a shared configuration / distribution saves a bunch of time.
It does make sense for developers to learn vi keybindings (so that they'll be able to use a vanilla vi in a limited environment), or to learn how to customise their programs for their particular situations.
To my understanding, the non-standard keybindings in distributions like Spacemacs provide are consistent, well thought out, and discoverable. (Which won't be the case with each ad-hoc customisation).
I do get the impression that Spacemacs (which I think inspired this project) adds a layer of abstraction too many, such that users who are stuck with Emacs might not have the capability to get themselves un-stuck without effort.
The open source landscape of plug-in development is under constant evolution and it can be quite a time sink staying on top of the latest and best tooling.
I see SpaceVim as something similar to a Linux distribution. The maintainers offer the work of selecting various packages inversion combinations that harmonize into a consistent system.
And just like any Linux distribution you can agree or disagree with the packages they choose or the default configurations it comes with.
I end up using a somewhat heavily customized SpaceVim that I personally like but it's my opinion the distribution is a very productive foundation.