[epage]

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

[kps]

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