Collected directions for Helix's future

[rauletaveras]

Preface

Recently I made a comment in an only tangentially-related thread about communication on Helix's future direction, but I don't want to be dead weight anymore, so I wanted to put some effort where my mouth is.

This thread is one small attempt to inspire clarity in conversation for users, contributors, and maintainers, about what Helix wants to be, so everyone can be on the same page. I hope something like this can save time, as contributors may understand what is likely not to be considered and not put their efforts into that, perhaps putting them where priorities lie; and maintainers will hopefully have less of a review burden. I also hope it can reduce emotional strain, as many nasty words have been said before—partly, as I see it, from a mismatch between what users want and expect, and what contributors and maintainers want and expect (and are reasonably capable of).

To any maintainers who may be reading this, I hope I don't come across as meaning to add responsibilities upon you when you already spend of your time to maintain this project. You are of course not required to participate, as isn't anyone. However, I believe it could help everyone be on the same page.

Introduction

This thread collects some dev-expressed intentions or at least heavily weighted ideas for Helix's development based on what I could find in the repo issues and discussions. This is not an official or unofficial roadmap; I am not a dev and can't read maintainers' minds, and this may be wrong and/or incomplete. With that being said, I more than welcome corrections and suggestions.

This is also not the place to discuss the details of each proposal. For that, please refer to the corresponding thread or wherever maintainers suggest.

The members of the GitHub organization that owns the repo can be found here: https://github.com/orgs/helix-editor/people. I link to it to remind readers that Helix is not made by anonymous "devs" and "maintainers"; rather, it's made possible by real human beings who could be doing anything else and choose to develop Helix. Keep that in mind.

Please refer to these documents too:

• The Vision, which, as far as I know, stands (including not being everything for everyone): https://github.com/helix-editor/helix/blob/master/docs/vision.md
• FAQ: https://github.com/helix-editor/helix/wiki/FAQ

Useful engagement with this thread:

• Corrections or additions to the information above
• Links to relevant discussions I may have missed
• Clarification from maintainers on timeline or priority uncertainties

What this thread is NOT for:

• Debating the merits of listed decisions (use the linked threads)
• Requesting new features
• General complaints about project direction

Governance

• Coming up with a policy for "built in" themes (Coming up with a policy for "built in" themes #10635)

Features

• Plugin system based on Scheme (Add Steel as an optional plugin system #8675 (comment)): Efforts are currently led by mattwparas working to implement his Steel interpreter, on his free time, despite much abuse. It is the only current candidate for a plugin system and is already accruing community plugins (https://helix-plugins.com/). There is, however, no time table as of yet as far as I know; remember this is a volunteer effort.
• Switching to a Scheme-based config (tracking issue: Switch to a scheme based config #10389 (comment)): This is as opposed to current configs, done in TOML.
• In-built spell-checking (How should spellchecking look in Helix? #14085)
• Sticky context (Feat: Sticky Context #6118 (comment))
• A GUI (Gui #11783): This is very eventually. It's a tough project to achieve.

What's NOT happening

• In-built vim keybindings: This has been discussed for literal years. Helix is not Vim and has chosen a different path (see vision above). It requires significant rewriting of Helix's internals. If this is unacceptable, you can confidently conclude this project is not for you. Please take your pick of other tools or support forks like evil-helix (and appreciatedly, support them there).
• In particular, vim-like "select next instance" behaviour for match in (or match around) (match in (or around) should favour selecting something on the current line #7191 (comment))
• Using milestones as roadmaps for next release (Next Release Milestone #13961 (comment)): At least for a good while.
• Regex find-and-replace in core Helix (Support regex substitution command #8572 (comment)).

In case any discussions come up, please do be respectful.