Would be nice to see a short screencast or at least a screenshot giving a sense of the workflow this enables (or maybe I'm missing it on the site -- looking at it on mobile).
That looks pretty great. I’m sold, I’ll give it a shot. I wonder if it blows away your existing config? Probably.
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)
I tried this a few months ago and it is nice setup out of the box. I tried to configure it and found figuring out the "right" way to extend by adding other plugins but it was hard to figure out. It involves multiple condig files some in lua, some in vimscript. I hope they make it easier / better documented in the future.
same problem here, both with lunarvim and with nvchad. I'm giving the latter a more extended try right now simply because I found its project structure a little easier to follow and customise than lunarvim's.
Please let me know how you get on. My email is in my profile. I also looked at nvchad and while it seemed simpler to understand, I also didn't think it was much easier to modify without changing code/config that would make merging updates hard in the future.
This landing page doesn't really provide any reasons to use LunarVim. What features does it have? What does it look like? What can it do that plain Neovim, Vim, or other IDES can't?
Speaking as someone who just yesterday was having a hell of a time getting NVIM configured with basic autocomplete, I was immediately interested. I would love to use VIM and it's ecosystem of plugins but I don't have 100s (1000s) of hours of patience getting everything tweaked and working well. Assuming OP works as well as it claims, I would literally pay a monthly subscription for it.
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.
So, I just gave it a shot. Seems pretty nice, definitely pretty syntax highlighting and basic autocomplete was simple to get up and running.
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.
I'm one of those 20 year VIM guys. After about 2 years I had a config that I haven't touched since. I could easily go without it, too, and frequently find myself on servers that I forgot to copy it over and didn't even notice. I usually only notice when I start trying to paste things (pastetoggle).
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.
This is my experience as well. I've witnessed colleagues and other developers boast about their vim configurations and plugin ecosystems (and supposed gains in productivity) non-stop ever since I started working as a software engineer professionally.
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.
I don't see the connection between the two things that you seem to be making: namely between having a bare setup and an increased productivity.
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.
Sorry, I guess I wasn't quite clear. I didn't mean to imply that a bare setup leads to better productivity.
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.
> 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
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.
I never said anything about not trying new tools, I'm talking about obsession, and it's become an addiction in some people. This is younger people than me AND older people than me. 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. It's not just one tool, either, they'll learn all the tools out there, find ways to solve problems in 10-20 different ways, then not solve anything applied or practical. When it comes to debugging they are just paralyzed because they don't know how the programming language works, just the tool.
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.
> 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.
Treesitter gives you fast, accurate syntax highlighting, indentation, and selection based on object type.
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.
I feel the same way after diving into the NVIM world a while ago. I put in the hours, spent like 10 hours trying to setup the environment to my liking, and ran into the same issues as you, autocomplete being a pain in the ass, having to figure out what these all plugins are etc..
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.
On the other side of the fence, I tried VSCode and the heaps of issues I faced with basic editing was so off putting. Even basic IntelliSense stuff like suggesting local variable names reliably and timely. Just give me my dumb trusty keyword completion.
Open the plugin-manager and read their documentation. But usually you need to install them yourself anyway. And because it's a GUI, discovering things is very easy. Just click and read.
I'd thought you were referring to after you've installed a plugin (or it got installed for you) and you wanted to know which plugin was doing a particular task.
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.
> I'd thought you were referring to after you've installed a plugin (or it got installed for you) and you wanted to know which plugin was doing a particular task.
>
> This is actually a problem in vim and emacs, but to my knowledge it's exactly the same problem in VSCode.
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.
> On vim and emacs on the other side you have simply no way at all to figure something out from the baseline
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.
> Do you actually know emacs? It's the most well documented application I've ever used.
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.
Yes, very unlike VIM. Have you ever used VS Code? The second you open a file with an type you haven't used before, the application is like "Do you want to install the extension for this?". Like 2 more clicks and it's done. VIM plugin discoverability literally could not be worse.
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.
And will you, on your deathbed, not regret all the time put under making a coding environment work to your liking? I personally can't imagine putting so much of my most valuable asset under what is essentially just editor config. But then again I'm a millennial so what do I know.
"The perfect blossom is a rare thing. You could spend your life looking for one, and it would not be a wasted life."
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.
The idea is to configure your editor so that it enhances your productivity. E.g. you spend 1 hour on editor config, but then you finish 8h of work in 6h because you work faster.
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 like asking a carpenter why he bothers to sharpen his tools.
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.
Especially compare it to SpaceMacs (https://www.spacemacs.org), another vim IDE with a similar name. I bet LunarVim is supposed to be an improvement of SpaceMacs, but how?
Spacemacs has holy-mode so it’s not just to make it emacs feel like vim. It’s curated and managed like a distribution, and in my opinion makes emacs much more accessible.
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.
There are already two Spacemacs-inspired vim distributions called 'spacevim' (maybe one has given way to the other by now, idr), so this might just be a similar project with a name that hopes to be more distinctive.
Slightly OT, but does anyone have tips for running nvim with docker?
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?
> I'll never understand why people want code folding.
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 mostly feel the need for (but rarely actually use) code folding in legacy projects with long functions/methods and long files - it can be helpful getting fixes in, when there's no tine/resources for a proper refactor.
Ed: but I mostly prefer clean code, short functions and concise files...
Even in cases when there are just 500 or 1k LOC with about 4-6 functions, code folding is immensely helpful in focusing on where you want and removing other distractions. Navigating between functions also becomes easier.
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 great when you want to hide some code you are not interested in, letting you then focus on the section that is of interested. You just fold the uninteresting code away.
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.
I haven't played with it, don't really use code folding, but one of the things Treesitter gives you is syntax based folding, so it might be what you're looking for.
I'm using tree sitter based code folding right now on my script. Everything goes haywire after opening and closing folds after a few minutes, partials folds with missing elements start appearing everywhere.
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.
I had the same experience as you. I never use folding but I thought I’d give it a shot to see if it enhanced my workflow at all. Figured that tree sitter should make it robust, but it ended up mangled almost immediately. It’s not something I care enough about to dig into deeper but I suspect whatever is going on will be fixed at some point.
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.
That seems like a load of weird and unnecessary generalised judgements.
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.
