Replies: 17 comments 45 replies
|
Maybe I’m old, but I’m quite happy that Helix doesn’t come around with the latest hype every other week. It does what I need, and it serves me well. YMMV ¯\_(ツ)_/¯ |
|
I'm missing some features like
|
|
You're right Helix is rock solid. My only real pain point is the inability to fold or style comments beyond simple colors. When documenting libraries on a vertical setup, those examples and docs take up the whole screen, which is tough for productivity. I’d love to help, but it seems everyone is focused on AI lately, leaving traditional OSS projects with low morale and little sponsorship. We can't expect one person to do everything. I really appreciate the author’s work...they’ve built something great and lovable. I’ll definitely be back for the next release. Helix is still the best editor I’ve used, it just needs a few more 'large project' features to fit my current workflow. |
|
How can we sponsor maintainers who have the bandwidth to help? If we really value the project, why not organize and crowdfund it ourselves montlhy? Even small contributions from everyone would add up. |
|
Got to admit I've been wondering whether Helix is a dead project over the last few months. It's always been slow to release and I'm okay with that. One of the reasons I left neovim was that it kept breaking every few months. Helix is very reliable, but in the last few months it honestly feels like the project has died. I hope I'm wrong! |
|
In my opinion, you can’t tell whether a project is actually dead just by looking at the release schedule. If I’m not mistaken, Helix was originally planned to have only two releases per year anyway. Which is hardly much at all. Personally, I’d prefer something like nightly builds, at the very least. Or simply more official releases. However, I also have to say that it’s actually quite easy to compile Helix from the current source code. I’ve been building new versions myself for quite some time now using the Git code. |
|
Of course I don’t know what’s going on behind the scenes, but imho the commits in the main branch are the usual library updates, bug fixes, and small improvements. Which are totally welcome, of course. But there are no indications which direction the Helix editor is heading to. This seems to happen behind the curtain, and that’s what probably most people are eager to know. |
|
I’ve been thinking about this a lot, and I see two main issues here:
Finally, as it stands, currently Helix is a solid editor for DevOps or lighter work, but for large-scale development, the closed architecture and reviewer bottleneck keep it years behind options like LazyVim. Anyway the first "brick" is there. |
|
Honestly, recently I started feeling like this project is dying slowly. I hope it does not. I really like this editor. We need major releases like Plugins Thank you maintainers for your great efforts. Without you this project might not make it this far, your work is loved and appreciated. |
|
Who are “we”? Of the things mentioned, code folding would be nice to have, but it’s not absolutely necessary for me. I don’t care about the other features. That’s why I always think it’s problematic when one person tries to speak for others. Regardless, over 80 commits have been made this month alone. So I don't really see any signs of a slow death. Especially since I suspect it's very likely that Helix is being developed by programmers in their spare time. |
I am pretty sure you tried here to speak for others 😅 Let's be honest and, as we Brazilian say, not try to block the Sun with a sieve. Helix is far behind many others mainstream text editors in terms of features. In Helix, we cannot:
The project really needs a change in direction because no open source project of this size can thrive without contributors. Currently, we have more PRs than Neovim. I saw numerous PRs closed because the OP lost interest after a long time. The PR that added text alignment capability was staled for years before it was closed unmerged. I started to use Helix because the motion seems much more interesting than Vim's. However, I completely lost interest because I am seeing the project stale. I was one potential contributor in issues and PRs, but I cannot dive into this endeavor noticing that I can take a long time to prepare a nice PR that will get "archived". Look at the plugin PR, it is good (although I completely disagree with the language choice). However, it is staying unmerged for years. On the other hand, we do not have releases. What's the point? Then treat |
And now we have 2 months without a single commit... This can happen with small projects, but it is mind-blowing seeing 541 opened PRs in this stage. |
|
I think, if maintainers are not doing helix as full time, They are doing a good job(looking at changes done by maintainers daily basis) |
|
I am taking this back.... |
|
I'm considering the Helix rolling release, I'm using the master branch version. |
|
|
|
This issue seems to be the most up to date I've found for gathering the maintainer's release readiness perspective (spoiler: it's not a direct answer): #15319. Worth remembering that the developers of Helix have pointed out many times that they do not care about popularity or feeling beholden to really any outside expectations. Forgive me for the slight tangent, but for development processes you have two differing extremes. One being the bazaar style development of "release early, release often". Then you have the other cathedral type development which is infrequent and is often associated with proprietary software. The latter can be more frustrating to users when source code is not available, but obviously that's not the case here. All that to say, nobody can argue either is more correct - it's a culture decision and depends on what goals the authors are trying to achieve. I do wonder if the project speed might pick back up to a somewhat more regular cadence once the plugin system is merged. I read somewhere that a release would likely be a prerequisite for plugins merging to give even more time to sort issues with such a major change. But who knows, just speculation on my part. |
|
I've been running off of main for quite a while and haven't had any severe issues.
I have lost hope that the plugin system would be merged this year. I hope it does, but I'm not going to hold my breath. |
|
The context of my comment seems silly now that commits have stopped flowing. I thought the maintainers were just not wanting to release until things are ready. But now it seems momentum is completely gone, which is weird given some of the previous comments about future plans. |
|
Today it's been exactly one year since the last official release of Helix Editor. Meanwhile, PRs have been merged and bugs have been fixed. And to my understanding, there is a general plan for a new release, which has been discussed roughly since May this year. I hope that we will soon see a new official release that then makes its way into package managers and distributions out there and makes the improvements that have been happening more widely available. I think it would help keep the momentum of this project going. Meanwhile, thanks to everyone involved for this great tool. Using it gives me joy every day. |
|
I was hoping they were waiting for that one year mark to cut the new release. I'm sure it will happen, sooner than later. |
|
Me too. |
|
For me, the weird part is that in the age of AI tools that are speeding up the writing of quality code, the development in this project seems to be going slower 🤔 |
|
Not to start a trench war over AI usage, but if anything that actually gives me hope. I like how Helix approaches a couple of things. Slower and deliberate development is one of them. |
|
Same here. I left Helix a long time ago when I saw that the plugin system would take a lot time to be released. A lot people here is saying: "Helix is fine as it is," but it is not, unless you have a very specific use case. For example:
Etc. And I noticed we reached a very strange point: there were PRs to solve some of those questions, but no maintainer reviewed, probably thinking that it does not fit the "core". However, without a plugin system, or you add features to the core or you do not have the features at all. For example, there was a PR to implement the alignment (a simple one). IIRC, after one year without feedback the op gave up Helix development and closed it. |
|
I get your point. The question is: was Helix ever intended to be an ‘all-purpose editor’, or do its maintainers believe that the editor is already fully developed as a programming tool and that anything beyond that is simply a nuisance? |
|
This is a good question and the maintainers should address that clearly. It is not good to take your time to make a PR, trying to contribute to an open source project, that will never be accepted. |
|
I see it as a design choice that fits some users and use cases and some not. For instance my nvim config was over 1k lines when I realised that I now longer understand enough of it and that I required a ton of plugins to do it what I wanted. Helix had most of what I needed build in and the default key-map worked for me. There was nothing to maintain for me as a user. Everything I really wanted worked out of the box. Well, that's obviously true for me personally, not necessarily for every one. So, I'm not waiting for the plug-in system to shape Helix into an IDE that I need to maintain on a per plugin basis. I'm waiting more for some maintenance releases that occasionally add some useful niceties. |
That’s totally fair, but the flip side of the 'batteries-included' approach is that you're locked into the core maintainers' roadmap. When you hit an edge case or need a niche workflow, Neovim lets you build a clean solution in a few lines of Lua. With Helix, you just have to wait and hope it gets upstreamed. The beauty of distros like LazyVim is that you get Helix's zero-maintenance experience 95% of the time, but you still keep the escape hatch for the other 5%. That nails the whole 'Helix promise': If Neovim is modern Vim, Helix is post-modern. But its just a prommise not a reallity. |
|
At first i missed code folding too, but it was just a habit/routine. Helix has it's means of navigating code, now i have other habits. What i still miss is: marks in scrollbar like in vscode that show where is what in the document, "saveable" search results that can be a separate tab, reorderable tabs, multicursor paste to complement multicursor copy, folder tree file navigation, general files management like renaming, creating, deleting. Maybe I haven't yet figured out "helix ways" for theses things. |
|
Still using helix and absolutely love it, would be nice to have new release this year. For me most of code work shifted to the agent living in the tmux tab next to helix, I use helix only to edit specifications and look into the code sometimes it's lightweight, don't need to be configured as neovim. In general would be great to have plugins system, proposed lisp is fine! |
|
It has been over a month since Helix had any code commits. Helix is a talent proposal, but currently it is not functional, completed software. Without full functionality, any talent idea would just be useless, at least for the most people. I think it is nearly impossible for Helix mode would finally prevail because of the slow development. It is pretty regrettable since the idea is so genius. |
|
I won't argue that point. You're right about alignment, as I said before. LSP is still fine with me. I ran |
|
Yes, I thought about it! But now there is LSP, a bunch of scripts to make the alignment, etc., so that I can turn Helix into something that can make me code without too much problems. At the end, I would need much more configuration lines than in Neovim or Emacs. I tried for some time to keep using it to learn the keybindings (I really think they are superior than Vim's), hoping that the editor will advance fast (specially in AI era). However, the development was just too slow. The problem was not lack of PRs, but very slow merging process: there are 531 open PRs, that's almost double than Neovim. justinmk (maintainer for neovim) has this quote in his profile:
I think this applies to Helix project. |
I have been using LanguageServer.jl in Neovim, Neovide, and VSCode for ages without a single problem. Helix is the only editor that needs LSP for a lot of things, and, let's be honest, LSP was never created thinking about a spell checker. |
|
But this is only the tip of iceberg. What really made me quit was the inability to ident your code based on tree-sitter or some heuristic (like the |
|
I root for kind of the opposite. But that's just me. I want to keep tools simple, specialised and separate but combinable (old school Unix style). The matter of open/rejected/abandoned PRs however is indeed worry-some, as is the public communication and release schedule. I don't know what is happening behind the scenes, and kind of hope that keeping this thread alive triggers some response about the roadmap. |
|
I am using helix from last 3 years. I am thinking about |
|
I genuinely like the keybindings in Helix over neovim and vim. But the lack of a scripting system is really starting to cause me to start thinking about going back to neovim. |
|
More than 2 months since the last commit. I'm getting worried... |
|
Similar things happened with Wezterm. The author felt responsible for the project, but had personal problems and couldn't dedicate time to it. While he was gone, people started to think about community fork. I think similar thing should be considered for Helix. I feel like the author(s)/dev(s) might be under quite a bit of pressure, yet it's not like anyone pays them for any effort, and they surely have personal lives, and users tend to just show up to whine. But I think it's healthy to let the community kind of run wild and reckless. I already have a LLM-maintained fork for Helix where I picked bunch of PRs that seems stuck, and added my own ideas. I would be interested in using and maybe collaborating on some kind of helix-staging fork project, where stuff would get broken more often, reverted, etc. but could be a testing ground for features. |
|
There are a bunch of ways to handle a situation like this. You mentioned one new approach, that became possible just recently. But whatever approach people like to choose, they would all profit from a statement about the State of Helix as a project. Nobody expects the impossible from maintainers, given this is a labor of love for which I'm hugely grateful. But knowing what roughly is going on (or not) would help to make an informed decision, e.g. to jump on a specific fork like https://github.com/mattwparas/helix or any other personal favourite. |
|
So, time for someone to build neohelix? :) |
|
The post-mortem editor? |
|
I've been pondering about the future of helix for a few months now and I'd like to hear what others think. I'm not sure what the future holds for code editors in a world where LLMs are writing most (if not all) of the code. I'm sure I'm not alone in this, but I'm finding that I spend far less time editing code and much more time managing a fleet of agents in tools like opencode. I'm not exactly happy about this turn of affairs. I've spent 25 years becoming a good developer and it's something I love, both academically and professionally. But I simply can't keep up, and I've got to admit that the code produced by LLMs is really good. If developers are spending less and less time editing code, what is the future for projects like helix? Helix used to be my main editor. I would spend 5 - 6 hours a day inside it and write every line of code myself. Is an incredible tool and I love it! I now use it as a lightweight notepad for the occasion that it's quicker to edit the code myself than wait for an LLM to do it. I also use it to manage context files and edit large prompts before copying it over to opencode. So I'm thinking, what could helix be if not just a code editor? How could it fit into this new way of developing code? This could be a really interesting inflection point for the project! A re-imagining of what code editors are used for. I'm really not trying to start a flame war here. I know how excited people get by AI. I'm not 'for' it or 'against' it. Even if I personally find it sad I no longer code as much as I used to. I'm just relating my experience over the last year or so and asking an honest question about what helix could become. |
|
This is, I think, not really relevant to this discussion. Whatever we'd like helix to evolve into, it won't if there is no development being done on it anymore. |
|
It's true that the immediate problem is that development seems to have stopped, but there are discussions about a community fork. I'm just suggesting that this might be a good time to think about the future of the project. |
|
I guess light editors like helix, neovim and emacs (altough neovim and emacs have big advantage due to being really extensible) are in a better position then big IDEs like Intellij, Visual Studio. IMO currently the best use case for such editors is to be really good tools to navigate and review code produced by AI agents and since they can be easily extended you can hook it into whatever AI tool (which are mostly CLI based) will come next |
|
I'd like to insert my voice here that, if development on helix has stopped completely, the project should be passed on to the community in some fashion so it doesn't die. |
|
I think the developers should give a clear statement for abandon, transfer a clear signal, which will benefit Helix that encouraging the fork, the continue of this project, instead of silence, which I think will impede the continuation. |
|
I went to https://www.lazyvim.org/ |
|
Lazyvim is great but I really like helix motions. If it weren't for the keybindings I might switch |
and others
Uh oh!
There was an error while loading. Please reload this page.
It’s a shame because Helix is great, but development has been frustratingly slow. It’s been nearly a year without a release, a roadmap, or any new features. It feels like the project is stalling out, so I’m moving to Neovim. The constant updates and 'mastodon' ecosystem are just too good to pass up just for a prommise without soul like helix.
All reactions