That's basically it; you get LSP, Treesitter, completion, snippets, ... all setup and ready to go. I've been using it for a few weeks now and it's pretty nice.
If you want to try it, use the rolling branch.
If you want to try it, use the rolling branch.
However, I think this project has the same issue as basic VIM/NVIM, in that if you're coming from something like VS Code it's not super obvious what plugins account for what functionality, or how you can replicate your workflow. For example, I had to google "Treesitter", which seems to be an AST parser. Okay, that's awesome that they have that, but what exactly do that do for me?
On top of that, immediately ran into issues with the autocomplete not picking up my venv, not completing function signatures, etc etc. And diving into the config now apparently means I need to learn the lua language.
Sorry don't mean to rant to you specifically. Just secretly wish I was one of these 20 year VIM guys with perfectly honed configs, but not enough time in the day.
You need to learn VIM itself, not the configuration. Just leave the config alone unless you are trying to do anything with tab spacing, or shut off some annoying feature, really. My config is ~40 lines long and just sets some basic things, and uses zero plugins.
I think the problem is that people are focused too much on tooling than work/coding. This is true of almost every developer that I've noticed. Leave the tool (mostly) alone, just use it. Tooling creates so much wasted time.
Yet here I am with an almost out-of-the-box configuration, not a single plugin and my productivity/output is usually considered (far) superior to those of my peers.
I've never understood this widespread obsession with tooling. It's virtually never been the bottleneck for me in any software project I was involved in. The main obstacles I've found are usually of social and/or organizational nature, followed by sometimes (far off) the involved technologies. Tooling isn't a concern.
We only have your word for it and it doesn't look factual to me at all.
F.ex. in Spacemacs the ability to fuzzy-find file names and file contents has saved me a lot of hours in the last several years. I absolutely don't see how I would work faster on those 1000+ files projects if I didn't have that functionality.
Want to elaborate on that point in particular? How does a naked editor help you in this scenario? Or will you claim that you know what's where in every single file in the projects you're working on?
Sorry to be a bit flippant but IMO you and your parent ventured way too deep into the "let's pat each other on the back about how minimalistic our environments are and how productive are we as a result" territory. Or "those crazy youngsters making their lives harder for no reason at all, am I right?" one.
The point I was trying to make was that constantly playing around with your tooling (configs, plugins, etc.) leads to very marginal productivity gains at best, especially considering the significant amount of time many developers invest into it. This is based on my observations and thus purely anecdotal.
Pick the proper tools for the job at hand once, learn them. Make minor adjustments if absolutely necessary, but don't get obsessed with tweaking.
The true potentials for gains in productivity lie in many other areas IMO; organizational/social/collaboration matters in your org, actual engineering skills, and so on.
Oh I completely agree, the problem is that is expected in many areas -- especially the JS stack (hence why tools like `esbuild` started emerging eventually).
I agree that many devs just "pimp" their setup all the time and that's not productive. Yep.
Sorry if I vented too hard; it did seem like you're one of those guys that scream "real men use vi!" but since you are not -- my apologies for the not very constructive comment earlier.
It's perfectly fine if you are using the tool and have found a happy medium, which sounds like you have. You found a tool, you used it. You didn't spend years tweaking the tool, learning how to make it look pretty, then move on to another tool and bend that tool to basically be a clone of the first one you used.
I never said anything about a "bare" setup. I'm saying you should find what works for you and use it.
I shouldn't have to teach people who know how 900+ WMs/DEs/IDEs to work what a hosts file is, why setting 777 on every file to solve any problem is a bad idea, or how software licensing works, but I have to do it regularly and it causes clusters to crash, deadlines to be missed, and bills not to be paid because they're too busy customizing their fancy redundant solutions to problems they aren't solving. Or installing a big 10 server cluster to solve something that can be done in 10-20 lines of code on a laptop instead with an off the shelf product that costs $100,000/year for one task and then ditch the product entirely.
I don't know why you took this personally...
As for editors vs OS, yeah I mean you have an OS already installed, right? Why create an overlay that does the same thing? Emacs has a web browser in Lisp, why? elinks/lynx/wget/etc exist to do exactly that on the terminal if you have to do a terminal based solution (downloading ISOs on a server, for instance). Or even just use Firefox on your desktop rather than trying 900+ browsers and never concluding which one will work for you, constantly switching back and forth and back and forth...
All I'm saying is use the tools. Customize it as needed, but don't become addicted to customization for customization's sake.
Sorry!
> To the point that they aren't USING the tools they are learning, just learning how to use it in such depth that they paralyze themselves.
Yeah, I've met those. And I completely agree that what they do is unprofessional. At one point you should just sit on your arse and do what you are paid for!
> I don't know why you took this personally...
Same reason why many others do -- I projected. :) Apologies.
> Emacs has a web browser in Lisp, why?
I am sure many would chime in to say how they love never leaving Emacs or how back then good email clients and web browsers weren't a thing -- but I am with you here, I think the effort and tool duplication must absolutely stop already.
There aren't very many of us the programmers in the world (I mean those who get sh1t done) and we shouldn't spread our efforts in meaningless individualism.
> All I'm saying is use the tools. Customize it as needed, but don't become addicted to customization for customization's sake.
Yep, 100% this. I actually do my very best to customize very little. I spend a great amount of effort [every now and then] to find the canonical way a tool [is expected to] work/works and just do a very thin layer of customization on top of that, versioning it with GIT and overall making sure I can nuke my $HOME from orbit, clone a few repos on a new machine, issue a few installation commands and be on my merry way.
> You need to learn VIM itself, not the configuration.
Signed, Another 20 year almost-no-config VIM user.
As far as the 20 year vim guys, I'm a 30 year vi guy and looking to get out of maintaining that mess that my vimrc has become. Trying lunarvim and kakoune.
But at least I found out I can just clone my vim plugins from git repositories with vim-plug, which was an improvement over my previous pathogen setup.
VSCode is just killing it with the feeling of having a complete setup and everything actually working, vs having to spend days figuring out how to setup a VIM environment these days.
How do you know what plugins account for what functionality in VSCode?
This is actually a problem in vim and emacs, but to my knowledge it's exactly the same problem in VSCode.
If you're talking about discoverability of plugins for certain functionalities that you're looking for, then yeah, it's easier in IDEs like VSCode because plugins tend to do lots of things (e.g. you don't install a plugin with the Java debugger, another with Java syntax highlighting, another to run tests .... it's just THE JAVA PLUGIN).
Spacemacs solves that for emacs by creating "layer"s which essentially bundle a bunch of emacs packages together so that you only need to install THE JAVA LAYER instead of the 10 packages you actually need. Not sure if NeoVim or LunarVim do that, but should be pretty simple to do.
No, it's not the same, because in VSCode you have ways to discover plugins and their purpose with basic knowledge. Just go through the list and read their description and find the one that matches the effect you search. They are even so well documented that they list the shortcuts, commands and settings they use automatically. And other parts of the app are evenly open and supportive. And if you not found it at the plugins, just open the settings and use the search. It's very easy to come very far out of the box with VS Code.
On vim and emacs on the other side you have simply no way at all to figure something out from the baseline. Until you learn to master them well enough to use their ways of doing things, you are just lost and abandon and can only hope to find some solution by googling for it and test things till it somehow works.
VS Code is a GUI, and even a very well-made one, and as such it's very open and self-descriptive. While vim and emacs are mostly non-descriptive at all and very cryptic until you dived deep enough to learn your ways. Both have their advantages in their own, but for this specific case, the cryptic completely loses.
> Spacemacs solves that for emacs by creating "layer"s which essentially bundle a bunch of emacs packages together
VS Code has bundles too. But it seems they are not that popular because in the end they are often too opinionated.
Do you actually know emacs? It's the most well documented application I've ever used. And it's famous for exactly that and it has a "culture" of including INFO pages for everything. I completely disagree with you on that.
You can use emacs like you use VS Code, clicking around and letting lsp-ui render those colourful help popups everywhere... I agree it's a bit more difficult to install the right packages, but that's the only difference I see between them. Once they're installed, it's basically the same, you need to just "know" how to do what you need and the tool won't magically teach you.
Yes, I'm using it for a long time now. And while emacs has its ways, they are not obvious, nor standard. That's what I mean with baseline, the common knowledge of users. Emacs out of the box is not very accessible, and spacemacs&co. do not change much in that regard. You still need to work on discovering the ways of emacs to gain something from it.
VS Code in that regard is different. It's a GUI and all the user need to know is how GUIs today work, which is common knowledge.
> it has a "culture" of including INFO pages for everything
Barfing out information for anything and everything does not mean it's good or helpful. Emacs documentation is also infamous for how dated and useless it can be, especially for beginners.
Right, and every VSCode plugin has perfect documentation?
> But usually you need to install them yourself anyway.
Maybe I'll write up a page with one-line summaries of the most useful VIM plugins - not only the IDE plugins - to help people find what they need. Any ideas for plugins or information to include welcome.
It's a bit like trying to write the perfect piece of software. Some people wouldn't bother with the effort and would instead use something written by others, I mean we all do that to some extent.
It comes down to, why do anything?
If you do want to make anything or do anything, it's never a wasted effort, even though you'll never succeed in doing that perfectly.
More likely the improvement is minimal and it’s recovered across many sessions. But still, the net result is supposed to be positive by a large margin.
You can't code effectively if you don't spend time optimizing your workflow, and there's no single thing as important for that as the environment you're actually typing the code into.
Over a 5 year time frame something that saves one second per day is worth about half an hour of time.
Something that saves 5 seconds 20 times a day is worth 50 hours of work.
Over 20 years its worth 2 hours and 200 hours respectively. It's probably pretty easy to find optimizations in any environment that are trivially a positive investment of what you correctly note is your most valuable asset.