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.
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.
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).
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.
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.
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.
- 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.
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.
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?
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).
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?
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.
[+] [-] mehalter|3 years ago|reply
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.
[+] [-] petepete|3 years ago|reply
https://github.com/nvim-lua/kickstart.nvim
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.
[+] [-] commandersaki|3 years ago|reply
Very happy with kickstart though.
[+] [-] zabil|3 years ago|reply
[+] [-] rektide|3 years ago|reply
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.
There's a decent amount of good discussion on Reddit on the new 3.0: https://old.reddit.com/r/neovim/comments/11ntuef/astronvim_v...
[+] [-] DogLover_|3 years ago|reply
[+] [-] skippyboxedhero|3 years ago|reply
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).
[+] [-] fileeditview|3 years ago|reply
If you already have some experience and want to configure your own this is a great scaffold to build your own thing: https://github.com/LunarVim/nvim-basic-ide
[+] [-] whazor|3 years ago|reply
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.
[+] [-] dotancohen|3 years ago|reply
Use Neovim just as if it were VIM. I've been doing that since I've started using Neovim, the only thing that I missed were encrypted files.
[+] [-] PartiallyTyped|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] threatofrain|3 years ago|reply
https://helix-editor.com
[+] [-] doix|3 years ago|reply
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.
[0] https://www.gnu.org/software/emacs/manual/html_node/emacs/Na...
[1] https://github.com/hoschi/yode-nvim
[+] [-] enriquto|3 years ago|reply
- 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.
[+] [-] TwentyPosts|3 years ago|reply
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
[+] [-] johnchristopher|3 years ago|reply
Documentation about adding languages seems more about adding new languages.
What should I do to get niceties ?
edit: ah, thanks search engine then arch wiki then https://docs.helix-editor.com/languages.html then https://github.com/helix-editor/helix/wiki/How-to-install-th...
[+] [-] freefrog334433|3 years ago|reply
[+] [-] buf|3 years ago|reply
Although I won't be using Astro because I like my current setup, I really enjoy looking through other people's configs.
[+] [-] ammmir|3 years ago|reply
Piping shit to bash and running npx whatever has really normalized this and it sucks. Your editor should be a safe haven.
[+] [-] kzrdude|3 years ago|reply
[+] [-] the_gipsy|3 years ago|reply
[+] [-] INTPenis|3 years ago|reply
[+] [-] dmix|3 years ago|reply
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).
[+] [-] qolop|3 years ago|reply
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.
[+] [-] least|3 years ago|reply
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?
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] rs_rs_rs_rs_rs|3 years ago|reply
My config never broken because of a plugin.
[+] [-] lawn|3 years ago|reply
[+] [-] renox|3 years ago|reply
[+] [-] anon23432343|3 years ago|reply
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 love vim motions :D
[+] [-] bionsystem|3 years ago|reply
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 ?
[+] [-] soperj|3 years ago|reply
[+] [-] hgomersall|3 years ago|reply
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.
[+] [-] tmdh|3 years ago|reply
[+] [-] circularfoyers|3 years ago|reply
[+] [-] hummus_bae|3 years ago|reply
[deleted]
[+] [-] dzonga|3 years ago|reply
[+] [-] w4rh4wk5|3 years ago|reply
[+] [-] jatins|3 years ago|reply
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.
[+] [-] mehalter|3 years ago|reply
[+] [-] alkori|3 years ago|reply
[+] [-] renewiltord|3 years ago|reply
[+] [-] crispinb|3 years ago|reply
Seems a bit daunting to move from an existing neovim setup. Lazy.nvim does look good so it’s a little tempting. Any hints to smooth the way?
[+] [-] phonebucket|3 years ago|reply
[+] [-] kzrdude|3 years ago|reply
[+] [-] cutler|3 years ago|reply
[+] [-] kzrdude|3 years ago|reply
[+] [-] erksa|3 years ago|reply
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.
[+] [-] benjaminwootton|3 years ago|reply