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?
It's a single, well-commented config file that will provide you with a neovim that has TreeSitter, LSPs, Lazy, Telescope and a few other useful tools. It's intended to be customised and tailored to your needs.
I love kickstart. Astro/Lunar, got me started with what's possible with neovim. I easily ported these features to kickstart. The benefit is an maintainable vim config and better understanding of lua to extend according to my preferences.
I've shied away from using preassembled vim toolkits, but I saw the pre-release for AstroVim 3.0 (just released) & really appreciated how configuration is now done in each plugin's native format, with AstroVim defaults one can extend (or ignore).
Previously AstroVim like many toolkits had it's own configuration system, which was top down & not 1:1 for the plugins. Now there's a much more bottom-up configurability granted to users, and the existing docs on configuring whichever plugin still stand.
This has greatly assuage my concerns abouts picking an off the shelf vim toolkit & I've become a happy new AstroVim convert.
I also appreciate the leap from the Packer plugin manager — which AstroVim 2 & I had been using — to lazy.nvim. It's much faster & requires much less hand holding. Most work is async, automatically compiled. And LazyVim detects changes & deals with it, rather than needing to kick the plugin manager.
Really great set of leading edge tools, well integrated here. Sensible defaults for a lot of good things one would have to wire up themselves. Divine option to have. The switch in configuration style should become a textbook example of core computing principles, is such a night & day practical difference: an example of how dangerous over-encapsulation can be & how nice having a less compositional & more aggregative model can be.
LazyVim is also quite minimal and super easy to get started with. There are some defaults which are bothersome but you can just turn them off. I've been using it for a while and it is pretty good.
it is by folke I believe the same author of lazy.nvim.
Why does packer somehow suck even more than what came before it? If I put my config on a new computer as you mentioned you need to "kick" it as in running :PackerInstall like ten times... Thanks for letting me know something that sucks less exists
I <3 Packer syntax, this is telling me I should look at a lazy migration. I have a make file that I run ~whenever i kickstart a new machine/vm that handles (most of) the annoyance.
For someone considering trying Neovim, the main obstacle is the abundance of GitHub projects promising an effortless way to get started. This abundance can lead to analysis paralysis, making it challenging to choose a path forward.
Astro is more of an attempt to replicate the full IDE experience. You can just copy-paste the above, and you are going (personally, I don't think nvim should be used like a full IDE, you really don't need the file tree or tabs, nvim has a better system than this).
Seconding this. I recently decided to give neovim a try again and found kickstart.nvim to be a nice starting point. Compared to all my previous attempts to get started with (neo)vím, this felt very understandable and effortless.
Telescope[1] is pretty central to navigation in Neovim these days. Think Ctrl-P in VSCode, but for any entity in your editor or workspace, not just files. Files in workspace, buffers (open files), ripgrep results, LSP symbols / references, etc. Also provides a live preview of search results without having to open them. Plus easily add results to your quickfix list, making large-scale edits easy.
I am not the person you asked, but with Telescope you can check/toggle open buffers very quickly, once you get used to it, its far quicker than using tabs(for open buffers).
I do have nvim-tree installed but I rarely use it as most times I either navigate files from within definition or go to file from imports or use grep or just search to open from Telescope.
Check out TJDevries's videos about Personal IDE and about kickstart nvim, he is a neovim and Telescope maintainer so he highlights is various usage very well.
IMO, when switching to neovim you have to struggle for a week or so to learn its ways than trying to make it identical to VSCode. I did not switch to neovim until I learned basic file navigation through vim emulator on VSCode.As that was the hardest thing for me when I first tried vim/neovim.
I remember learning vim and not understanding how people used it because you couldn't change files. Using buffers, and some kind of search to load files in made it clear.
Telescope is a good option for file search, and this also has grep.
I found it much easier to install a list of twenty plugins myself.
The problem I had with these projects is that in order to use them, you first have to read the plugin documentation before understanding how to use it.
I used these projects to check what plugins they were using, and then I would go to the plugin Github and check what is does. Then if I like it, I would copy it inside.
I don't know if I'm contradicting myself but LazyVim has a lot of configuration code in addition, lots of custom keybindings and tweaks to each plugin's config.
But it's transparent in the sense that the lazyvim documentation site reveals how each part is configured.
It's doable by hand. I wanted to run LSP servers in Docker so I don't need to juggle versions and dependencies and virtual environments on my main machine and nothing out of the box had this. Took a couple of days. It's sad that it's perceived to be so difficult that an extra thing is needed to make it usable. As a result everyone uses those and the actual plugins have poor docs and API, if not that I would've spend less than a day I guess.
LazyVim has the following completion/lsp plugins loaded (and I've added nothing): cmp-nvim-lsp, mason-lspconfig, mason, neodev, null-ls, nvim-lspconfig, luasnip, and there's more that load on demand.
The best way to deal with such situations in my opinion is flipping a coin and letting everything up to chance. Given the [minimal] stakes, the cost of analysis / paralysis is far greater than any regret from an imperfect config.
All plugins run arbitrary code and basically any and all of them gains access to your entire filesystem, home network, etc. Even if you properly containerize and firewall everything (99% of people won't) it can at very least read your possibly private source code. The stakes are not so small.
I think I was misunderstood, or more likely did not convey the message correctly. Given a set of acceptable configurations that pass your litmus test, there's little - if any - reason to waste effort in deciding which to go with.
I assumed that the commenter had a relatively narrow list of what they deem acceptable, e.g. 2 or 3 or even 4 configurations.
The approach though is more general than this scenario and can be applied in almost every case with low stakes while absolving the person of the regret they might feel for their choice and reduce the time spent deciding in search for "perfection". The goal is to reduce regret and indecisiveness.
I see, I read it as "which do I choose from all the starter templates". I can understand the paralysis, trusting/vetting a whole template is trickier than if you start from blank slate and add plugins one by one as you go and develop intuitions for who are reliable plugin authors that usually don't break your editor etc. But a template is also tempting because more productivity faster, and going plugin by plugin with sometimes poor docs seems daunting.
It gets brought up a lot in vim discussions. It's missing a few major things for me;
1. Tabs (like in vim). I've found only vim and emacs have tabs in a way that makes sense to me. Kakoune also has a cool model, where I can use my window manager (or tmux) to recreate tabs.
2. Code folding, I like to fold everything as soon as I open a file to get an "overview" and then slowly unfold as look into the details. Wasn't in Helix last time I checked.
3. Narrowing. Emacs has it built in [0], (neo)vim requires a plugin [1]. Similar to code folding, when I'm working on a large function, I want to pretend it's the entirety of my buffer.
Other than that, I'm not convinced that changing the order of key combinations makes sense. Kakoune did the same, I'm not a fan. I spent too long "thinking" in vim mode.
I think it's great at bringing the "floor" up, it's much easier to get productive in helix. But the ceiling is lower than vim.
These are not tabs the way vim does tabs. It just shows you which buffers you have opened. Vim tabs allow you to quickly switch between collections of windows. Here's a better explanation written by someone else[0]
it doesn't - I use `gq` frequently to format things without the LSP, a concept that helix lacks completely.
An example is: I write a long comment string on one line, then `Vgq` breaks it into a comment block according to the line width I have set for the file.
- Love the possibility to download a single-file static executable that works out of the box, without need for a bizarre install method
- Love that basic vim keybindings work
- Hate that it does not come with a manpage hx.1
- Mildly annoyed by the default look and feel (line numbers taking horizontal space so that my code does not fit on the 80 column terminal, ugly white bar at the bottom, ugly negative-contrast completion hints, lines longer than 70 columns silently disappear to the right of the screen forcing me to do very unergonomical horizontal scroll, tabs should be 8 spaces by default not 2)
- There's really nothing wrong with this program, but it just feels like a vim clone, and I don't see the point to move from vim in my case.
> - There's really nothing wrong with this program, but it just feels like a vim clone, and I don't see the point to move from vim in my case.
It's a vim clone that works out of the box with LSP support, telescope, etc. that would require hours of plugin tinkering toil. I don't need to manage, configure, update, and depend on plugin authors.
It's great. I install it on every host I need to interact with. Quality of life things like `helix --health` further reduces toil.
Thanks for the explanation. I guess that these features are important for their users, but I'm definitely not one of them. (In fact, lsp is so ugly that it's a positive feature not to support it, but I digress...)
I think it's great. I picked it up on a whim, and it then managed to turn into my default (code) editor.
The good:
-Closeness to Vim and the floating option menu (if you eg. press g, it shows you what options you have in the lower right of the screen) make it really easy to learn and be productive with
-Some amazing defaults. m (for select inner word, delimiter, function, class, etc.) is great, the multi-cursor mode is absolutely amazing and wipes the floor with Vim's "search and replace" functionality for all sorts of reasons.
-Multi-cursor mode and the s-key (take a selection, filter by regex) is absolutely amazing in general. Makes it incredibly easy to perform repetitive edits.
-All sorts of stuff just works
-Built in treesitter for movements and highlighting, and built-in LSP support which works great
-Helix makes NeoVim look old and crufty. When loading NeoVim it was common to run into annoyances with plugins, where it felt like various plugins or functionalities are "fighting" each other over control. Helix feels very slick and modern in comparison,
-you don't need 90% of the classic vim plugins most people use, since they're already built into the program
The bad:
-Still lacks certain features, apparently softwrapping lines at screen-width is currently being worked on, and that's a feature I've been waiting for
-Can't do some of the fancy stuff you can do with vim plugins, eg. LaTeX support with PDF-viewer connection, or Jupyter notebooks, or whatever sort of highly specific thing you might want to do
-Not as good at editing plaintext as Vim. Vim has eg. das ~ "delete as sentence", Helix doesn't. Couple that with lack of softwrapping (for now), and it's a pain
It's pretty great, and I see no reason not to use it. I run into situations where Helix isn't suitable (eg. LaTeX or plaintext), and then I just switch to regular NeoVim. The keybinds are close enough that it's easy to switch back and forth
It looks nice and fresh but I don't understand how to quickly add support for a language. hx --health show red crosses everywhere, LSP column has red crosses with elm-lang, elvish, etc. or None.
Documentation about adding languages seems more about adding new languages.
I'm using it to edit rust code, and it's great that it works out of the box. I was looking for something feature comparable to vs-code, and struggled with emacs and neovim plugins. It is changing, but I've been happy with it for the last 6 months.
I want to like helix and have tried to daily-drive it
it just seems missing so much still
a quick example - in emacs, I can do "comment-region" and I will get to comment out a selection with the right comment sequence - afaik even something as simple as that doesn't work in helix
so many other things
minor modes are important...in emacs I can have spell checking as a "minor mode" when editing markdown...how do I do this in helix?
easy support for lsp is fine but that means helix is useless if you don't have lsp for a file format you are working on...like .txt! emacs is still a great TEXT editor
I think to many neovim users, the term is absolutely synonymous. I don’t know anyone that prefers the feature set of vim to neovim at this point. The benefit of vim/vi is that you will probably have it on most unix systems by default.
This comment will probably be a bat signal for vim users though.
Many of these vim distros (haven’t used AstroNvim specifically) with plug-in managers automatically download and execute random code on your system anytime you start the editor or open a new file type. I just want my own secure config that doesn’t do random network calls when I’m trying to open local files.
Piping shit to bash and running npx whatever has really normalized this and it sucks. Your editor should be a safe haven.
You can turn autoscan (fetch from git repos) off, update should normally be opt-in already. You can use a lockfile and only update on demand. That's a more sane option. But yes, auditing 50+ git repos is not something I've attempted.
Random node packages processes truly sounds horrible for both security and performance, but you do want at least one LSP process spawned per filetype, right?
Separating out the LSP process from the editor is a good idea. One sure hopes the blast radius is small enough if there’s a vulnerability. My beef is really with the auto-update culture. If I can specify lock files for plugins, it helps, but no way most people are going to have the time or expertise to audit editor plugins.
I guess it’s the classic security vs. UX compromise!
Ok so the natural question from a long time vim user is; don't all these plugins make (neo)vim less stable and therefore defeats the purpose of using vim in the first place?
As someone who tried to use Spacevim for a year+ I will say that a) it makes it more stable in a way, instead of your own hyper-custom config that could still break on updating vim/plugins you have a hundred plus other people having the same issues to debug it + a big community finding best of class Vim plugins doing the work of iterating it for you, but b) it's a bit rigid and even with the ability to tweak them you're better off either fully committing or not doing it at all because you'll be caught in between their complex config and your own breaking changes which is the worse of both worlds (as a starting config it's still very useful though).
This is ideal for people who can't be bothered to invest the time in a very personalized set up (like Linux desktop VS MacOS) but still want something more powerful and widely accessible than VSCode for most languages (the big exception being VSCode for Typescript/JS, as a Vim obsessed dev I've finally conceded to Code, since that's my day job).
You're assuming I have a hyper-customized vim setup. Which I absolutely don't, I thought it was implied from my question that I am the opposite. I try to keep my setup as vanilla as possible because the main reason I enjoy vim is its reliability.
And of course when I say reliability, I don't just mean from crashing. I mean from unnecessary work maintaining plugins and their infrastructure.
In that case it would 100% make it less stable. I respect the vanilla Vim folks but I could never do that.
Just curious, do you also keep bash/zsh vanilla as possible? I hate sshing into servers without my rc, which is a downside. But I also don't do much sysadmin stuff so it's not a very common issue.
I use bash, and yes it's pretty vanilla. I have a custom PS1 line with some added info but no colors, no multiple lines like a lot of people do.
I've been using Linux (or Unix) for 25 years and it works well for me. I can work in large projects with many files and directories. I never even heard of people automatically transferring their RC files to remote servers. That sounds quite convenient to be fair.
> the big exception being VSCode for Typescript/JS
Why? As a neovim user with a lot of ts/js at $job, curious what if I'm missing especially useful (outside of the proprietary live-remote-session stuff)
Almost entirely because I develop Vue 3 w/ Vite on top of Rails 7 (plus a very opinionated Eslint + Prettier set up) so cutting edge plugin support = key, combined with a team that uses a mix of Vim and other stuff. VSCode's community will always completely dominate Vim for Typescript support and it's far easier to establish VSCode as the standard editor than a mix of custom Vim configs.
Even the base Vue VSCode plugin + native TS engine doesn't support my needs for modern Vue 3 <script setup /> syntax without a ton of false positive redline errors. When I switched to using Volar my life became way easier (Neovims LSP plugins are usually a year behind the VSCode native ones let alone plugins):
In my experience of using LunarVim (which is also a preconfigured neovim). It is incredibly unstable. Plugins often don't work well with each other. Keybindings overlap. You do it with the hope of having fewer things to configure but what ends up happening is you create more config to disable slow default plugins, or add workarounds to existing ones. Updating neovim or lunarvim always breaks my config. These things aren't the least bit backward compatible.
I'm slowly switching to helix, and this time around will be forcing myself to use the defaults, and not adding a single line of config.
Vim is a tool for editing text, and plugins exist to make manipulating text easier or make it easier to write code. I use vim over other editors because of its editing paradigms. I extend vim because I want to make my life easier. Emulation of vim in other editors is often fine to excellent, but it does make the ergonomics of using and extending the editor a little bit more complicated. Most Emacs modes need to have extensions specifically written for Evil so that things don't step on each others toes, vim's plugins are all written with that already in mind. It then becomes a matter of plugins not fighting with each other for keybindings, though that isn't really that much of an issue for me.
Given this is how I use vim, it doesn't detract from the purpose of vim for me. I'm not entirely sure what you think the point of vim is? Do you use it as your primary editor and just choose to eschew plugins for the sake of stability or do you only use it for quick edits?
I have a pretty vanilla spacevim setup and it takes ages (sometimes more than 10 seconds) to start up on a very modern m1pro or recent i7. Not really sure why.
There are timing tools which let you see which plugins are causing that. That happened to me twice with Spacevim and both times it was fixed by removing a single plugin or a single line in the config related to an update to a plugin.
If someone is new to VIM/NVIM: I would go first with the basic.
I have seen a lot of people being overwhelmed with this pre-made configs and lost interest really fast. Also if your not into config stuff and making it yours then maybe something like vim/nvim is not for you. If you want to use vscode use vscode. Its not about the tool but how good you know the tool :)
I use vim daily and have been for years. I find those initiatives really interesting and especially I see things like org mode for vim which, although it is only a subset of org mode for emacs, could help me with some usecases.
However I also find those things overwhelming. Just looking at the readme I feel like I'll need a few nights of learning and weeks of practice to figure out a workflow, plus it won't be available soon on my few computers and ever on my many servers. What I like in vim is also it's ubiquity and simplicity. I know my vim config by heart (it's just 6 lines) and just type it in when I login and I don't like the installed config.
How would you or anyone recommend approaching a transition to those kind of framework or frontends or whatever it's called ?
It looks interesting. I'm always keen to consolidate my complex config.
Neovim is great, but does anyone know of any neovim front end that properly supports middle click copy and paste through the primary buffer? I've sort of hacked something with neovim-qt, but it misses highlighting that isn't click-drag-unclick.
I use nvim mostly when I want to edit some conf file in the terminal. Recently I wanted to change that. So I tried AstroNvim, but it was so slow, like I was getting input lags. Now I am using mainly vscode and helix. I want to use vim so badly, but I can't.
I noticed the credits of the README mention a few other configs I hadn't looked at before including NvChad, LunarVim and CosmicVim. I'll have to try all these at some point to compare them to what I started using not long ago, SpaceVim.
just wish some of these vim+ thing would come with sane defaults. so that no one would configure anything.
ready editor with lsp for most commonly used languages etc.
I think that's why VScode won.
This looks actually really nice! I especially like the debug functionality being treated like a first-class citizen, emulating VSCode's panel layout. I might actually be using this in the future. :)
I spent few weeks playing around with AstroVim and NvChad recently and both of them were pretty good. I personally found NvChad configuration easier to modify.
Yet I found myself pretty far from any IDE level configuration that I'd have wanted. It'd have taken me months to get to the level of productivity that Intellij offers on day one. I settled on Intellij with Vim bindings.
At this point I just want JetBrains to make a terminal based editor.
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.
What did you find missing with nvchad and astroVim? The reason I ask is that I switched from intellij to lunarvim (similar to nvchad) about a year ago, and I felt like it only took me a couple hours to add a few extra keybinds and plugins like trouble.nvim and copilot.lua to make my IDE experience match intellij
I tried to get LSPs properly set up in Vim but I think with the help of the these "distributions" in neovim, I finally found something where neovim works much better than Vim. For me, neovim is finally showing its net positive value.
The VSCode Vim-keybinding plugin is subpar, so making a VS-Code plugin extension to nvim seems like the better choice indeed.
Jokes aside, beautifully composed aesthetic, and particularly like the right window in the preview. Will prob do something similar with imenu in emacs. Seems like a way more usefull than seeing a non-readable minimap of your source code file.
I'm a long term vim user and now exclusively a neovim user. I adopted this from the first time I came across this. It's pretty neat, it does break from time to time but there's always a GitHub issue describing a workaround. It's pretty stable these days and breaks far less comparatively.
The vim ecosystem is starting to look a lot like the JavaScript ecosystem, new shiny projects every month! I’m just joking of course, as vim is a far superior entry into world of technology than JavaScript has been, look, I’m joking again!
Unlike Javascript, this isn't a whole new framework that you have to learn all over again. This is just a set of configurations that change the look and feel of NeoVim - which doesn't take re-learning if you're used to Vi/Vim. The whole point of this is that you can install NeoVim as your editor, install this config, and get started without having to customize things yourself. Most people will tweak it as they go in order to fit personal preferences, but this provides a good starting point.
It's a _lot_ saner than the JS ecosystem in my opinion.
I want to stress that for anyone looking to use Neovim as an IDE (lite), all you need is something that speaks the Language Server Protocol (LSP). You don't really need to download all these configuration frameworks.
- No debugger support, I'll use a CLI debugger or an IDE if I need one.
I've been using this setup for very a long time, and I barely touch my init.vim anymore. Here's a recent thread from the neovim subreddit where the OP talks about how much effort it takes to properly setup a configuration framework https://www.reddit.com/r/neovim/comments/11p6iiu/i_love_vim_...:
> I want to fix my problems and consolidate my environments BUT setting it up is too painful and I don't another hobby as a job (I already have servers and a 3d printer lol). I've tried multiple times this week to setup either pure neovim, lunarvim, nvChad, astrovim and LazyVim starter and there's always something that I can't find how to change even after searching online and not even taking into account that setting it up takes like a day for each. I don't really want to dedicate a whole month to reading docs, debugging and discovering plugins to fix issues that i'm hitting and I don't wan to blindly learn some commands to then throw them away because that distro didn't work out.
Does someone know how the outline in the second image is created? I'm using tagbar but I would prefer to get the outline from LSP or Treesitter and only fallback to ctags.
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.
As a DOOM Emacs user, I feel this looks great as I always use vim/nvim for simple file edits (but maybe thats the drawback of using something like Doom on old hardware)
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.