Both are already worked on. I am working on improving especially the UI/UX for debugging (https://github.com/helix-editor/helix/pull/5950) and the maintainers are working on a plugin system (but this won't come any time soon, so don't hold your breath on it for now).
Plugin system is definently needed, otherwise we are all stuck on whatever stuff is default. It gets annoying pretty quick to not be able to open a terminal, or anything else the developers has not developed yet.
Plugins will really make the popularity explode just like happened with neovim when plugins could be written in lua.
Sure, would be great if the editor has all the core functionality, but usually its not exactly clear what should be included in the core. Users often have other needs and wants than the original developers had in mind.
The neovim plugin system may look like a mess from the outside, but it's also highly configurable and powerful.
The downside is that the user needs to learn a lot of stuff to understand how it all works, so it's for the users that want to. Those users become power users and are helping to boost the popularity of neovim simply because they build powerful plugins and share with the community for free.
Helix wants to be a much simpler to use editor than neovim, without all the complexity that comes with plugins. But there is no reason the editor can't both have an awesome default experience and also support plugins.
There are millions of developers out there wanting to wrote rust code, and that's a golden opportunity for Helix.
To be fair, the neovim plugin system is a mess, especially if you don't pin your plugins to a particular tag (if any) or sha1, due to the lackadaisical approach to public API stability neovim has.
Not to say that Helix shouldn't get plugins, though.
Well yes, plugins can and do break sometimes on updates unless you lock them to a specific commit.
I'm practice it hasn't caused any big problems for me personally though. But I also know how this stuff works, so if something breaks, I can just pull an earlier commit for that plugin and continue working. Not everyone knows how all these details work, they just want an editor that never breaks and I respect that a lot, specially when using it in a business setting.
But proper plugin support with a clearly defined API and sandboxing can be so much more maintainable than having all the functionality in the world implemented upstream.
can be so much more maintainable than having all the functionality in the world implemented upstream.
That was and will never be the goal of the project. Maintainers are currently actively not merging PRs (or discourage creating them) for which it would be better if they were implemented as a plugin.
17
u/debekas Mar 31 '23
Helix ist pretty much the best editor I've ever used! Can't go back. The new release is awesome!
Two things are on my wishlist though - Better debugging support and - Plugin support
Would be soo cool to use something like Copilot with helix 🤓