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.
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.
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.
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.
> - 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.
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.
> 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)
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.
Readit News
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.
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).
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'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?
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!
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?
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.
Very happy with kickstart though.
Just watched it. Pretty decent introduction to kickstart!
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...
Are there any other vim toolkits that take the astroVim 3.0 approach?
it is by folke I believe the same author of lazy.nvim.
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).
Could you expand on what is that system?
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
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.
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.
Deleted Comment
https://helix-editor.com
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
- 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.
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.
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
https://docs.helix-editor.com/master/configuration.html#edit...
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...
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
maybe one day helix will be an option, not today
But it definitely misses support for multiple lsp's per file and plugins.
Otherwise it just works.
With `hx --health` you can see what executable you need to have a specific LSP working and most of the languages are really zero conf.
I'm also using the master branch version, as the last release is some time ago, but it still works even though it is not a "stable releae".
For example if you have typescript and eslint.
Helix right now can't run both.
So you would need to run eslint in the terminal.
Although I won't be using Astro because I like my current setup, I really enjoy looking through other people's configs.
Edit: why the downvotes? This is a Lua based neovim setup that can't be used with vim.
This comment will probably be a bat signal for vim users though.
Piping shit to bash and running npx whatever has really normalized this and it sucks. Your editor should be a safe haven.
I guess it’s the classic security vs. UX compromise!
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).
And of course when I say reliability, I don't just mean from crashing. I mean from unnecessary work maintaining plugins and their infrastructure.
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)
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.
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?
Deleted Comment
My config never broken because of a plugin.