For anyone who’s curious, this is the state of discussing this feature: https://github.com/helix-editor/helix/discussions/8572
I’m not an authority on the helix ethos, but I’ve contributed a bit and hung around long enough to have a good read on their stance on most topics. The project is still young and managing the growing pains of getting a lot of traction relatively early. I think the devs value keeping the maintenance footprint small to keep the project sustainable.
The philosophy of helix’s design is to be a more convenient kakoune, not necessarily a vim. vim is much more widely known, so that analogy springs up more often, but this idea of using piping out to an external command for most operations comes from kakoune.
For features that would introduce significant maintenance overhead, may jeopardize the performance of a more common workflow or where the design goals are still maturing, the team tends to push such suggestions toward being developed as plugins when that system is added. I get the impression that they see the value of this workflow, but would prefer to see it battle tested as a plugin first.
For those that look at this and still think the solution might just be more money, first recognize that Google donates only to keep Firefox as a viable competitor to avoid anti-trust legislation.
If we raised half a million dollars, we haven’t saved anyone any money except Google - they’d simply donate only 100k next year so Firefox remains competitive, but not successful.
I don’t disagree with the sentiment of the post, but we also have to realize that we’d only be improving things after the first ~600k.