You can definitely put all of your configuration into a single file for AstroNvim if you want.
In the docs it shows the minimal configuration to get AstroNvim running which is <10 lines in your ~/.config/init.lua file and then anything else you can just drop in that same file if you want. (https://github.com/AstroNvim/AstroNvim?tab=readme-ov-file#mi...)
If you haven't tried out AstroNvim v3.0 yet over the past couple years when you were playing around with AstroNvim I would definitely recommend trying it out. The new v3.0 release made a lot of improvements to the configuration structure to decrease abstraction and make things easier. Although, if you have a setup that you like with NvChad that's definitely a good approach as well. All comes down to personal preference.
AstroNvim is using aerial.nvim which is a great code outline plugin. It has several supported backends on top of LSP and Treesitter it also supports Man page structure and Markdown structure explicitly. We also use the API for building the breadcrumbs at the top of each window as well!
Thanks, I will give it a try! Maybe event AstroNvim, because it's very close to my current config, which is probably pretty outdated in many places. Especially the all in lua config is very compelling.
Very cool to see this with such good discussion on Hacker News! I am the lead developer for AstroNvim (https://astronvim.com/) and am happy to answer any questions that anyone has. This new release has been a while in the making and is truly only possible because of the great community we have been building. We have been able to receive so much feedback, see how many of our users are using this pre-configuration to drive their own setups, and have been able to work together to meet their needs.
The biggest goal of this latest major release was to decrease abstraction from our configuration schema. Rather than implementing our own ways of configuring plugins, we expose it to the user in the same way that they would configure it themselves. That way users don't have to relearn Neovim configuration.
Another cool project that we have been spinning up along side this new release is AstroCommunity! (https://github.com/AstroNvim/astrocommunity) This repository aims to empower the community to get more involved with the project and to share their own configurations of plugins that we might not want to ship with the base installation of AstroNvim. This ranges from single plugins such as colorschemes, all the way up to full language packs that setup language specific plugins/language servers/debuggers.
> The biggest goal of this latest major release was to decrease abstraction from our configuration schema. Rather than implementing our own ways of configuring plugins, we expose it to the user in the same way that they would configure it themselves. That way users don't have to relearn Neovim configuration.
Glad to see this! This is one of the reasons I originally avoided AstroNvim and other pre-built configurations.
Overall though, my experience with neovim has been bad. I've tried hand-built configurations multiple times but (1) I could never port my vim config just right, some common features would crash, and it was a sour taste having to research how to build an editor out of all the random building blocks (2) LazyVim finally clicked for me but I still get a lot of configuration errors, intermittent crashes, etc. So far I'm still giving neovim a try though I still use vim when I want to avoid all of that mess (e.g. quickly opening / closing files without a lot of float windows).
> Overall though, my experience with neovim has been bad. […] and it was a sour taste having to research how to build an editor out of all the random building blocks
I've been in the same boat. I've been using vim for a long time (and before that nvi, and before that vi) and have over time built up a configuration that mostly works. Opinionated configuration systems don't do it for me, since they inevitably conflict with my opinions and muscle memory.
Until quite recently neovim couldn't handle my vim configuration, and in particular my key maps (issues with modifyOtherKeys) so I always gave up quickly. Recently I tried again, in order to use rust.vim, and got much further; I now only need a little bit of conditional configuration and a bit of divergence in active packages.
Agreed. @mehalter, why would I want Astro vs, say Lunar? What itches is it scratching? I'm a fairly happy LunarVIM user, though I largely feel that Lunar is more oriented towards a VSCode experience, where I'm more of a "just give me vim with LSP and other productivity enhancements and a sane config" guy.
There are a few key differences here. When AstroNvim was originally created it was very difficult to have complete control over NvChad from the user configuration. When AstroNvim was starting out, our configuration engine was the first thing that we wanted to have really locked down. No matter what opinions we dictated from the core of AstroNvim, every single option should be able to be changed from a user's setup.
Next we really wanted to focus on providing a more stable base. NvChad at the time was not following any sort of version releases and had breaking changes all the time. This lead users to updating their editor and things just randomly breaking. We wanted to set up AstroNvim to follow more rigorous software development practices to help decrease this friction for the user. With our updater you can say that you only want to update within a major version release and then you don't have to worry about fixing breaking changes until you have the time to do so.
Along with this providing a stable base was the battle of managing the distribution of plugins that do not follow any set rules. This led us to our current approach to plugin management in AstroNvim. If you are using the stable release channel of AstroNvim we actually pin all of our core plugins to either a known working git commit or to their current major release version if they follow semantic versioning. This makes sure that updating plugins on the user side won't randomly break core AstroNvim functionality. Naturally this doesn't apply to plugins that the user manages themselves, but at least gets us to as "stable" as we can get it.
The main drive behind all of this is a lot of people use these types of tools to drive their work life. The goal I try to keep in mind is I want to minimize the number of work days people use to their text editor all of a sudden not working for some unknown reason.
Some other key differences:
NvChad also sets up a lot less than AstroNvim under the hood when it comes to language servers/etc. so this does lend to a faster startup time in NvChad than AstroNvim, but better out of the box experience (imo) in AstroNvim for an extremely small start up time cost. So if you want something that truly provides a very good base and do all the other heavy lifting of configuration yourself, NvChad is a really great option!
Also if you want to see what I mean in my other comment about "out of the box" experience, here is a simple demo video of going from a completely fresh installation of AstroNvim to having language servers, treesitter parsers, and even debugging code without having to even restart the editor: https://www.youtube.com/watch?v=04z9v0xMDkw
This is cool! So basically it's enough to add astrocommunity/pack/go plugin and it will handle all plugins/sitters/syntax/etc needed for the lastest Go nvim experience, right? I've been looking for such an option for a long time.
Yup! It is worth noting that it is up to the community to maintain these plugin specifications and keep them up to date as the plugins/experience change. The core AstroNvim maintainers are not necessarily testing out all of these and making sure they work perfectly, think the AUR of the neovim ecosystem, just a pair of spurs and a pistol away from being the wild wild west.
Feeling a bit bad about putting up a support question here, but here I go (long term vim user and sponsor of the initial nvim fundraiser).
I am using a dark-on-black terminal style, but when I launch astrovim it seems to superimpose a light on dark color scheme. How can I default to a non-invasive colorscheme?
This is a little aggressive. Sure, Balena offers a proprietary licensing to make money for their cloud software, but all of the technology is built with open source first. You can self host OpenBalena (the open source parts of Balena) and do your own deployments locally. I'm not sure if going after open source projects that can make money is the best way to promote open source software.
> I'm not sure if going after open source projects that can make money is the best way to promote open source software.
but im not doing that.
I'm going after open source projects that can make money (by building closed source infrastructure) taking other peoples open source projects and moneifying them into a new """open source""" project (where 99% of the meat is in closed source cloud infrastructure) as a way to piggy back off of the work of other people so that they can advertise on hacker news.
Like, if the repo actually added something substantial and new to the project, that would be one thing.
If this was an article that explained how to do the gluing/config work this github repo does, also, another thing. even if hosted/made by the cloud company. That at least appeals to the intellectual pursuit.
If you want something that is more of a static kiosk setup, there is a different Balena supported project that supports more of this style use case. Without the need of casting or connecting with Airplay
I'll never touch Balena anything since they put phone-home in Etcher (a simple tool for writing a local file to a local
flash blockdev, essentially just a GUI front end to dd). I can't spend the time to audit their software for spying, and they already burned up whatever default level of trustworthiness they had.
Not quite Chromecast functionality, but there is a similar project from Balena that adds Spotify Connect, Airplay, and Bluetooth to a speaker using a Raspberry Pi
I have the same set up to generate both my resume and my website using an HTML template. Makes it easy to update one YAML file and update both my CV and my personal website
The man page is a very nice touch! Do you have source in GH or elsewhere about this harness? I am using Restructured text and rst2pdf but this looks so much nicer!
In the docs it shows the minimal configuration to get AstroNvim running which is <10 lines in your ~/.config/init.lua file and then anything else you can just drop in that same file if you want. (https://github.com/AstroNvim/AstroNvim?tab=readme-ov-file#mi...)
Here is a user on GitHub that has a single file AstroNvim configuration: https://github.com/20k-ultra/dotfiles/blob/master/nvim/init....