I really would love to move to helix but they can be… stubborn about what gets into the core. And if you start having to go to a plugin (which isn’t even possible last I looked) to get table stakes features in, it kind of defeats the purpose of a modern batteries included modal editor. But it’s still a cool thing I’m glad exists.
> but they can be… stubborn about what gets into the core.
Yes, as an onlooker who is similarly cautious about moving to helix, I consider this to be a major risk factor.
I've watched the maintainers waste dozens of hours of contributors' time, and leave the project with no improvement afterwards.
I would actively warn against anyone trying to contribute to the project.
The maintainers simply don't know how to run an open source project, and it's unlikely you will be able to accomplish anything.
It's fine for a project to not accept contributions, and if you don't have the skillset to leverage contributor labor, then it's better to be upfront about it.
That being said, I hope they figure out the plugin system, or someone forks the project to add the missing table stakes features.
> The maintainers simply don't know how to run an open source project
Can you explain why you feel this way? From an outsider’s perspective, Helix seems like an impressive piece of software with a growing community. I don’t see what the maintainers are doing so wrong
Being able to build high quality software alone is a distinct skill from being able to make a group of engineers productive. Neither are soft skills, it comes down to how the software is architected and how well you can produce, understand, and communicate designs with the other collaborators.
I do consider helix to be an impressive piece of software, and I agree that the user base is growing, not necessarily the set of effective maintainers though. The maintainers don't seem to have any aptitude for coordinating engineering effort. That would be fine, if they were honest and direct about it. SQLite is a project which does not accept contributions, I think helix should do the same.
Put differently, I don't expect the large community to have a meaningfully positive effect on the quality of the software, because the maintainers have not demonstrated the competency to effectively utilize that labor. I expect helix to continue slowly improving at whatever rate the maintainers can make important changes themselves.
It’s a ridiculous and inflammatory claim to make about a clearly successful project with an enthusiastic community of users who love it. The maintainers have day jobs and have a clear and narrow vision that they don’t want to mess up by carelessly expanding the pool of maintainers. That is the entire explanation!
This is what killed all the momentum that Elm had at one point. While that's a language and not an entire editor, it does serve as an illustrative example of being far too strict about accepting changes to core.
For projects without funding, there is typically a trade off between a polished coherent product, which means saying no a lot, and a bloated product that has enough maintainer bandwidth to stay around. The second means saying yes to things which may not make the product better, in order for newcomers to feel bought into the project and want to maintain it.
For something like an editor, where whole features can be turned off by default, there's quite a bit of leeway to add bloat and get newcomers to buy in, without actually making the product worse.
For a programming language, a feature in the language has to be used by everyone. So the leadership has to say no a lot to keep the language high quality, and that makes it hard to get newcomers to buy in.
Unfortunately you can't have it both ways without paying people to maintain the project. Elm was good because the leadership said no...often.
It's dead because the leadership said no so often that no one wanted to help maintain it. No one is going to waste their free time working on a project that won't accept their ideas, nor should they.
A language like Go doesn't have this trade off. If the Go leadership rejects a google employee's proposed language change, the employee still has to do maintenance chores as directed to keep their job.
> That being said, I hope they figure out the plugin system, or someone forks the project to add the missing table stakes features.
They decided on an obscure Lisp flavor as the language (instead of WASM), so I don't hold my breath for a powerful plugin system, more like slightly more convenient configuration language.
It’s not even an obscure Lisp flavor. It’s Scheme. You’re getting thrown off by the fact that they need their own embeddable interpreter for it written in Rust.
I actually moved from VS Code to helix and happily used it exclusively for about 4-5 months, at that point I had list list of things I really wanted in my editor. I took that list to neovim and haven’t looked back!
I really hope to be able to use helix again in the future though, there was a speed advantage in helix and less janky window management.
But for me to do that they might have to allow full vim motions as well
Every time I've used Ubuntu their packages have seemed pretty out of date across the board. Is there something extra Neovim is doing here to make that worse?
I think so too, a lot of my friends have told me they had a great experience with helix, but vim keybinds are rooted too deep, and it's also the sunk cost of having built the config over an entire year. But, I think I would give it a try sparingly.
There are a number of reasons I use Helix but one of them is the maintainers’ approach to managing development of the editor and accepting (or not) contributions.
For me, slow and opinionated is a feature, not a bug.
