Hacker News Reader

> 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.

I just clicked in out of curiosity, and AFAICT the homepage doesn't say anywhere what AstroNvim actually is.

This is a great point, thank you so much for pointing this out! I will update this immediately!

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.

Very cool to see this indeed! I always had an eye on AstroNvim.

I'm currently on a slightly customized NvChad setup and am happy with it. It mainly transitioned me to lua configs, which has been a good decision.

How do you compare with NvChad? It's a slightly different set of tools, yes, but why did you think it needed another 'preconfigured vim' distribution?

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.

Nice work, added to https://neovimcraft.com/?search=astro

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?