Show HN: LunarVim – An opinionated, extensible, and fast IDE layer for Neovim
lunarvim.org
lunarvim.org
I just recently dropped vim and my existing vim config (which took me forever to get autocomplete correctly), for nvim 0.5 with builtin lsp. The effort to get nvim lsp configured vs. any of a handful of autocomplete plugins I’d tried using previously in vim was night and day. Nvim is a fantastic project and LunarVim looks like a great complement.
(edit: it doesn't blow away your existing config, and it has some very respectable config documentation)
At the very least, i want to know what background the author from, what kind of language he is familiar with, etc…
The page give no info on that.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> You need to learn VIM itself, not the configuration.
Signed, Another 20 year almost-no-config VIM user.
How do you know what plugins account for what functionality in VSCode?
> 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.
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?
https://github.com/neoclide/coc.nvim
You can go down the native LSP route too but I suspect this is what gave you trouble. It certainly confused me.
I’d say in both cases, once you have editor support for syntax highlighting, refactoring, autocomplete/intellisense, live/interactive error reporting, etc. you’ve stepped out of the realm of text editing and squarely into IDE territory.
A fully loaded Spacemacs install (and by the looks of it, LunarVim) is not Eclipse or VS with reSharper, but they compete and are well beyond a simple text editing.
Typically my vim runs in an environment where I won't necessarily have all interpreters and linters installed. I run my apps, e.g. rails, in a docker container together with ruby etc. Other apps use JS, or python etc. But my dev box won't have all those directly installed. Not to mention using different versions.
I kinda managed to hack neomake[0] to run rubocop via docker-compose, but it wasn't easy and not all linters support something like this... What's the best way to solve this? add (neo)vim to each app docker container that I use? Or is there some trick to let it access all those dockerized interpreters/linters?
https://github.com/tpope/gem-ctags https://github.com/tpope/gem-browse
That effortlessly let's one go to the definition of various library code. Not sure if there's something similar for Python and typescript?
Sometimes cognitive load is correlated with visual load. Perhaps most people don't suffer from this problem? But I do.
Other times code works as an outline, and folding branches (for example) is useful to visualize the logical outline without immersing in implementation details.
Occasionally I need a refresher on a bit of code, not something super in depth, and folding is good for giving me a mental prompt.
Folding allows me to keep context in an API (if it's logically laid out in the file) for reference without having additional clutter in my editor. (This is a personal thing that's also probably not terribly applicable for many people who might prefer a collapsible tree in their IDE.)
If I'm stuck in configuration file hell, especially XML ones (here's looking at you finicky Eclipse stuff I've had to deal with in the recent past), having folding is super helpful for skipping past completely irrelevant content.
I mean, I could go on, but I've found it useful.
When you fold everything, you get a nice overview of all functions that you can jump to.
Great for warming up on unfamiliar code when you want to know, what's exists, not just where something specific is.
Also, the act of dismissing a feature as useless that you don't personally use is apparently one of the hallmarks of FOSS community.
Ed: but I mostly prefer clean code, short functions and concise files...
I guess it's pointless to talk about this because the utility of code folding is subjective for some people and in my anecdotal experience so far, any feature that doesn't work in their favorite $EDITOR is branded as useless.
Folding is also great for cutting or copying large blocks of code.
For example image a block of code spanning several pages.
It can be difficult to know where that block starts and ends, making it hard to mark the region for that cut/copy action.
But with folding it is easy to condense the block into a single line and then copy the entire block by just copying the single folded line.
Falling back to the old regex based code folding makes things much more accurate (albiet still sometimes buggy) but everything becomes slow as hell, especially when I scroll pages using Ctrl+f,b.
People are proselytising NeoVim as an IDE and as a replacement for VSCode when it lacks features that VScode supports out of the box without extensions or plugins. It's not just code folding, indent visualizations are buggy in NeoVim as well, another feature VSCode supports out of the box without plugins.
Almost everyone seems to be circlejerking about things like LSP and there are dozens of plugins for it including a built in plugin but NeoVim lacks basic features like code folding and indent visualizations. Goes on to show where the focus of the community is - flashy and attractive over functional.
I'm still using NeoVim because I'm too used to it but that's the only reason. Mental Threshold.
The FOSS community really is filled with fundamentalists.
There’s nothing wrong with people wanting to improve tooling and LSP has ushered in a new era of hybrid approaches where you can use the editor you love but get enhancements to the experience. Tree sitter also provides a new interesting way to interact with code, but the whole ecosystem is in its infancy.
All of this stuff is improving rapidly and personally I’m happy with it now.
I don’t want / need a full IDE and there’s nothing wrong with that.